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Preface 



On behalf of the program committee, it is our pleasure to present to you the 
proceedings of the fourth Recent Advances in Intrusion Detection Symposium. 

The RAID 2001 program committee received 55 paper submissions from 13 
countries. All submissions were carefully reviewed by several members of the 
program committee on the criteria of scientific novelty, importance to the field, 
and technical quality. Final selection took place at a meeting held on May 16-17 
in Oakland, California. Twelve papers were selected for presentation and publi- 
cation in the conference proceedings. In addition, nine papers, presenting work 
in progress, were selected for presentation. 

The program included both fundamental research and practical issues: log- 
ging and IDS integration, attack modeling, anomaly detection, specification- 
based IDS, IDS assessment, IDS cooperation, intrusion tolerance, and legal as- 
pects. 

RAID 2001 also hosted two panels, one on “The Present and Future of IDS 
Testing Methodologies,” a subject of major concern for all IDS users and desi- 
gners, and one on “Intrusion Tolerance,” an emerging research area of increasing 
importance. 

Dr. Bill Hancock, Senior Vice President and Chief Security Officer of Exodus 
Communications, Inc., delivered a keynote speech “Real world intrusion detec- 
tion or how not to become a deer in the headlights of an attacker’s car on the 
information superhighway” . 

The slides presented by the authors, the 9 papers which are not in the pro- 
ceedings, and the slides presented by the panelists are available on the website 
of the RAID symposium series, http://www.raid-symposium.org/. 

We would like to thank all authors who submitted papers, as well as the pro- 
gram committee members and the additional reviewers, for their efforts. Special 
thanks go to Felix Wu for handling the conference arrangements, Niranjan Bal- 
walli for maintaining the paper submission Web site, Giovanni Vigna for publi- 
cizing the conference, and Andreas Wespi for maintaining the RAID Web pages 
and preparing the conference proceedings. Finally, we thank all the RAID 2001 
sponsors. 
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From Declarative Signatures to Misuse IDS 



Jean-Philippe Pouzol and Mireille Ducasse 



IRISA/INSA de Rennes - Campus Universitaire de Beaulieu 
35042 Rennes Cedex, France 
{pouzol , ducassejOir isa . f r 



Abstract. In many existing misuse intrusion detection systems, intru- 
sion signatures are very close to the detection algorithms. As a conse- 
quence, they contain too many cumbersome details. Recent work have 
proposed declarative signature languages that raise the level of abstrac- 
tion when writing signatures. However, these languages do not always 
come with operational support. In this article, we show how to transform 
such declarative signatures into operational ones. This process points 
out several technical details which must be considered with care when 
performing the translation by hand, but which can be systematically 
handled. 

A signature specification language named Sutekh is proposed. Its 
declarative semantics is precisely described. To produce rules for exist- 
ing rule-based IDS from Sutekh signatures, an algorithm, based on the 
construction of a state-transition diagram, is given. 



1 Introduction 

Many formalisms and algorithms have been proposed to specify intrusion signa- 
tures in order to detect misuses. Among the intrusion detection systems (IDS) 
briefly described by Axelsson in P, one can cite state-transition diagrams in 
STAT 0, colored Petri nets in IDIOT condition-action rules in AS AX [7|, 
expert systems in EMERALD m- The languages proposed in these articles are 
strongly dedicated to the underlying search algorithm. As a consequence, the 
signatures are cluttered with many operational details which make them hard 
to specify and maintain. 

More recent approaches propose to specify signatures of intrusions in a declar- 
ative flavor, for example MuSigs defined by Lin et al. m and LaDAA defined 
by Gerard |E|. LAMBDA, defined by Cuppens and Ortalo and ADeLe, pro- 
posed by Michel and Me EEI, are languages dedicated to describe both attacks 
and signatures. The aim of all these high-level languages is to specify signatures, 
regardless of any detection process, by describing relations between events in an 
audit trail. However, either these languages ignore functionalities provided by 
others, or they do not offer any operational support. 

This article firstly proposes Sutekh, a declarative signature language provid- 
ing a combination of functionalities at least as complete as the union of what 
is offered by other declarative systems. In addition, we show how to produce 
operational detection rules from declarative signatures. 
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Sutekh provides sequence, alternative, partial order, negation, event correla- 
tion by logical variables, condition verification and alert triggering. These func- 
tionalities are formally defined by a declarative semantics that rigorously de- 
scribes which sequences of events in an audit trail are considered as occurrences 
of a signature. This semantics extends earlier work of Chakravarthy 0 in the 
context of active databases. 

In order to implement the signature detection, we propose to produce rules for 
rule-based IDS from declarative signatures. We first define an algorithm to build 
a graph structure (called Signature Graph or shortly SigGraph) representing the 
evolution of the detection process. From this graph, rules for different target IDS 
can be automatically generated as illustrated by two examples involving ASAX 
and the expert system P-BEST used in EMERALD. 

Our SigGraph is a state-transition diagram close to the one used in STAT. 
Its systematic construction, however, exhibits a number of technical problems in 
particular with the combination of logical variables, partial order and negation. 
With our approach, these problems are solved once for all. 

The main contribution of this article is, therefore, to exhibit a whole chain 
of transformations from declarative signature specifications to operational rules. 
When specifying or maintaining a signature base, one can thus concentrate on 
the essential aspects of signatures captured by the declarative semantics. The 
operational aspects will be automatically addressed. 

The remainder of this paper is structured as follows. Section |2 presents 
Sutekh, illustrated by the complete specification of a signature. Section |3 gives 
the declarative semantics of Sutekh. Section 01 details the algorithm we propose 
to produce rules for rule-based IDS. Related work is discussed in section 0, and 
the paper is concluded in section |0 

2 Overview of Sutekh: A Declarative Signature 
Specification Langnage 

This section presents the syntax and the informal semantics of Sutekh, a declar- 
ative signature specification language. We first introduce basic elements called 
filters, and then show how to combine filters to build signatures. Finally, we 
propose a complete example of specification. The formal semantics is given in 

Sec.|3 

2.1 Basic Blocks: Filters 

Filters are “single event” signatures. They are used to define constraints on an 
event. Figure [D shows an abstract syntax of filters. Each constraint specifies 
a relation between an event field and a term. A term can be either a set (in 
fact, a disjunction) of constant values or a variable. If an event satisfies all the 
constraints, this event matches the filter. Four constraint operators are defined, 
equality (=), inequality (!=), bitwise-and matching (&=), and regular expression 
matching (#=). This list could be extended if necessary. 
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< Filter > ::= 


< Constraint 


< Constraint > 


< EventField > < Op > < Term > 


< Op > ::= 


II 

II 

II 

II 


< Term > ::= 


< ConstantValue >'*' | < Variable Name > 



Fig. 1. Abstract syntax of filters in Sutekh 



< Signature > ::= 


< Signature N ame > ( < Arg Name >* ) < Body > . 


< Body > ::= 


< Filter > 


1 


< Body > ( then | or | and | if_not ) < Body > 


1 


< Body > such_that < External Fred > 


1 


< Body > trigger < External Froc > 


1 


< SubSignature > 


1 


( < Body > ) 


< External Fred > ::= 


< Fred Name > ( < Term >* ) 


< SubSignature > ::= 


< Signature Name > ( < Term >* ) 



Fig. 2. Abstract syntax of signatures in Sutekh 



2.2 Signature Specification in Sutekh 

Figure El shows an abstract syntax of signatures in Sutekh. Signatures are de- 
clared within < Signature > statements which are similar to function declaration 
in traditional programming languages. 

Signatures are built in a compositional way as shown by the rule: 

< Boby > :■.= < Body > ( then | or | and | if_not ) < Body > 

— Sequence (S = Si then S2): an instance of S is found if an instance of Si 
is found and if an instance of S2 is found in the remaining part of the trail. 

— Choice (S = Si or S2): an instance of S is found if either an instance of Si 
or an instance of S2 is found. 

— Interleaving (S = Si and S2): an instance of S is found if instances of Si 
and S2 can be independently found in the trail. This describes a partial order 
on events which compose the instance. 

— Negation (S = Si if_not S2): an instance of S is found if an instance of Si 
is found, and if there exists no instance of S2 between the first and the last 
events of the instance of Si. 

The base case of this inductive definition is a signature composed of one 
filter. An instance of a single-filter signature is found if an event matches the 
filter as described in Sec. 12 . 1 1 
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The suchThat statement is used to call external logical predicates. An 
instance of signature S = (Si such.that P) is found if an instance of S is found 
and if predicate P holds. 

The trigger statement is used to call an external procedure, for example, 
to report an alert when an instance of a signature is found. Since the expression 
(S trigger A) is a signature, it can be used as a component of another signature: 
this provides a means to raise “partial” alerts before the attack is completed. 



2.3 An Example of Signature in Sutekh 

This section presents an example of a signature to detect an attack exploiting 
a buffer overflow in the admintool program distributed in the Solaris environ- 
ment. This vulnerability has been reported in the CERT advisory CA-1996- 
16 |2j. admintool is a graphical front end to several administration tasks, in 
particular to install new software packages through the pkgadd command. All 
Solaris packages contain two files named pkginf o and pkgmap. The first step to 
overflow admintool is to create these two flies in a directory (/tmp/EXP in this 
example) and put an overflowing string in them. The second step is to execute 
admintool and install the fake package located in /tmp/EXP. 

Figure El presents a signature of this exploit in a BSM m audit trail. After 
the declaration of several constant values corresponding to event identifiers in 
BSM, we define two Alters: 

createFileLike (Regexp, File, Userid): a Alter for events corresponding 
to Ale creation (AUE_CREAT and AUE_0PEN_WC)E1 The name of the created file 
must match the regexp in parameter Regexp and is unified with the parameter 
File. The real user ID is unified with the parameter Userid. 

execProg(ProgName, Userid): a Alter for events corresponding to program 
execution (AUE_EXEC and AUE_EXECVE). The name of the executed program is 
unified with the parameter ProgName, and the real user ID is unified with the 
parameter Userid. 

These two Alters are used in the last signature, admintool (). Since the two 
files can be created in an arbitrary order, the and operator connects the two 
createFileLike Alters. The use of the User variable as parameter of these Alters 
specifles that the Ales must be created by the same usefl The names of the two 
Ales are respectively bound to variables Filel and File2. 

We add a constraint, using the such_that statement and the external pred- 
icate same_directory, which verifles that the names of the two Ales have the 
same preflx (ie. the Ales are located in the same directory). 

Using the then statement, we specify that the creation of the two Ales must 
be followed by the execution of admintool. The variable User specifles again 
that this operation must be performed by the very user who created the Ales. 

^ In fact, at least eight system calls can create a file on Solaris systems. Adding the 
six missing identihers presents no difficulty. 

^ This attack can also be performed by several users. In such a case, the signature 
would be a variant of the one shown here. 
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’/. External predicate used : same_directory 
’/. External procedure called : admintool_alert 

% 

’/o Declaration of constants 

const AUE_CREAT = 4. "/ eventID for syscall ’create’ 

const AUE_OPEN_WC = 77. "/ eventID for syscall ’open’ in write/create mode 

const AUE_EXEC = 7. "/ eventID for syscall ’exec’ 

const AUE_EXECVE = 23. "/ eventID for syscall ’execve’ 

% 

’/. Filter for file creation 
createFileLike (Regexp, File, Userid) 

= [ eventID = ( AUE_CREAT I AUE_OPEN_WC ) , 

realUserlD = Userid, 

path #= Regexp, 

path = File ] . 

’/. Filter for program execution 
execProgCProgName, Userid) 

= [ eventID = ( AUE_EXEC I AUE_EXECVE ) , 

path = ProgName , 

realUserld = Userid ] . 

5 ^ 

’/. Signature for the admintool exploit 
admintoolO 

= ( ( ( createFileLike("*/pkginfo" , Filel, User) 
and 

createFileLike("*/pkgmap" , File2, User) ) 
such_that same_directory (Filel , File2) ) 
then 

execProg("/usr/bin/admintool" , User) ) 
trigger admintool_alert (User) . 



Fig. 3. Signature in Sutekh of an exploit using admintool 



Finally, the trigger statement specifies the external procedure used to report 
the alert (not detailed here). 



3 Semantics of Sutekh 

This section presents the declarative semantics of signatures in Sutekh. We 
formally present what we call event, filter and event matching. Then, the seman- 
tics is inductively defined on the syntactic constructs proposed in the previous 
section. 




6 



J.-P. Pouzol and M. Ducasse 



3.1 Event Matching 

An event is a structure where fields are named. Let £ be the set of event field 
names and V the domain of values of these fields. 

Definition 1 (Event). An event is a set of pairs (l,v) where I G C and v GT>. 
We note Z(E) the value v of field I in event E. 

Definition 2 (Filter). Given a set of variable V, a filter F is a set of constraints 
{Cl, ..., Cn}. Each Ck has the form (Ik , I'k , tk ) where Ik G £ an event field, 
rk is a binary relation (eg. equality), and tk S {V GV{'D)) is a variable or a set 
of constants (we note V(D) the power set ofV). 

Definition 3 (Substitution). Given a set of variables V = jVi,... ,Vn}, a 
substitution a is a total function from V to T>. 

Definition 4 (Constraint Satisfaction). We say that an event F satisfies a 
constraint ( 1 , r , t ) with a substitution a iff : 

{ t GV ( 1{E) r a(t ) ) ) A { t G V{T>) 3x G t . { 1{E) r x) ) 

Definition 5 (Event Matching). We say that an event E satisfies a filter F 
with a substitution a, and we note (E0o- F), if and only if all constraints in F are 
satisfied by E. We also say that “event E matches filter F with substitution a”. 

3.2 Instance of a Signature 

Definition 6 (Trail). A trail is a totally ordered sequence of events. The i*** 
element of a trailT is noied T[i]. We call i the “position” of event T[i]. 

It is important to distinguish the position of an event from the time informa- 
tion it contains. Since signatures express relations between events in the trail, 
the semantics of signatures only takes into account the position of the events. 
However, constraints on time information can be declared in such_that state- 
ments. 

Definition 7 (Instance of a Signature). Let T be a trail, S a signature and a 
a substitution of the variables of S. We characterize an instance of the signature 
S, in trail T, between two positions ia and ip, with the substitution a, by means 
of the relation: T, cr, (ic, ip) [= S. 

FigureElinductively defines the 1= relation on each Sutekh syntactic construct. 
It is important to note that the bounds ia and ip are respectively the position 
of the first and the last event of the instance. 

The Filter definition ensures that the bounds coincide and that the event 
occurring at this position matches the filter F with substitution cr. 

The then definition ensures that instances of and S 2 occur and that the 
ending position of the first part of the sequence is strictly lower than the 
starting position of the second part. 
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The or definition ensures that at least one of the two parts of the choice occurs. 

The and definition ensures that the two parts of the interleaving occur and 
that the starting position (resp. ending position) of the whole instance is the 
minimum (resp. maximum) of the starting positions (resp. ending positions) 
of the two parts. 

The if_not definition ensures that an instance of Si occurs, and that no instance 
of S2 occurs between starting and ending positions of the instance of S'!. 
The bounds of the search interval of S2 are strict < i\ and < if}). The 
lower bound is strict because, from an operational point of view, one only 
wants to search for S2 if the beginning of an instance of S\ is detected. The 
upper bound is strict because if an event satisfies both the last filters of S\ 
and S2, an occurrence of exists, and an alarm must be raised. 

The suchThat definition ensures that an instance of S occurs and that a{Pred) 
holds. We note a{Pred) the result of applying the substitution a to the 
variables in the predicate Pred. 

The trigger definition merely ensures that an instance of S occurs. Indeed, 
this statement is used to produce side effects that do not interfered with the 
detection process (eg. raising an alarm, producing debugging information). 



4 Transforming Sutekh Signatures into Rules 

The previous section detailed the declarative semantics of Sutekh. This seman- 
tics, intended for the end-users, gives a precise meaning to signatures without 
introducing operational considerations. This is motivated by the fact that end- 
users do not need to know how the search will be performed. As a consequence, 
the transformation of declarative signatures into operational ones must be done 
automatically. Therefore, we propose to compile Sutekh signatures into existing 
misuse IDS formalisms and focus on rule-based systems. This section proposes 
an algorithm to achieve this task. 

The algorithm builds, as an intermediate representation, a state-transition 
diagram called a Sig Graph. In the following, we first present the different com- 
ponents of this graph, and then show how operational rules can be generated 
from this structure. The remainder of the section then details the three main 
steps of the Sig Graph construction. 

4.1 SigGraph Definition 

A SigGraph is a kind of non-deterministic finite automaton. Each node corre- 
sponds to a state in the process of searching an audit trail for signatures. Arcs 
are oriented and labeled with Sutekh filters. Outgoing transitions from a node 
correspond to events the IDS reacts upon when it is in this state. Transitions 
may be labeled with predicates declared in such_that statements. Intuitively, 
this means that the transition can be made if the event satisfies both the con- 
straints of the filter and of the predicates. Procedures can also be attached to 
transitions: they are called by the IDS when the transitions are performed. 
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P, a, 


{ia,ip) Filter F 


iff 


T, cr. 


{ia,ip) ^ S'! then 5*2 


iff 



T, cr, 1= S'iOrS'2 iff 

T, a, {ia, ip) ^ S\ and S 2 iff 

T, cr, {ia, ip) S'! if_not S2 iff 

T, cr, {iaiip) S such.that P iff 
T, cr, (i«, ifj) ^ S trigger P iff 



{ia = ip) A {T[io]0„F) 

3(ii,i2).( 

T, cr, (io,, i\) N S'! 

A T,a, (*2, 5'2 

A (ia <ii<i2< ip) ) 

Pf cr, (^Q., ip) N (S*! 

V T,cr, *S '2 

T, cr, (ii, ^2) *S'i 

A T, cr, (* 3 , ^ 4 ) 1= 5*2 
A ia = min{ii, i^) 

A ip = max{i2, i^) ) 
P^ cr, (io, i,g) N 5*1 
A V(ii,i2)-( 

(ia <ii<i2 < ip) 

T, cr, (ia,ip) ^ S2 ) 

P,a, {ia,ip) N S' A cr(P) 

P, cr, (^Q., ip) N S' 



Fig. 4. Semantics of signatures in Sutekh 



Given a signature S we write Var(S) for the set of all variables used in S, 
Pred{S) the set of predicates used in such_that statements and Proc{S) the 
set of procedures used in trigger statements. We also use the standard notation 
P{E) for the power set of a set E. 

We give a formal definition of a SigGraph graph, and Fig. El illustrates this 
definition with an excerpt of such a graph. 

Definition 8 (SigGraph). Given a signature S, SigGraph(S) is defined as a 
4-tuple (P, Init, E,T) where: 

— P is a set of nodes, P C {Id x V{Var{S)) x {rec | nonrec}) 

— I nit is the initial state of the graph, I nit G P 

— Pinal is the set of (labeled) final states, Pinal C {P x {accept \ reject}) 

— T is the transition relation, T G {P x A x P) where 

A is the set of transitions, 

A C {Filter x V{Pred{S)) x V{Proc{S)) x [forward \ backward}) 
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Nodes. They are identified by an identifier Id. Each node contains a set, named 
BoundVars, of variables that have been assigned a value before reaching this 
state. Nodes are also labeled by “rec” or “nonrec” . This fiag indicates if the state 
is recurrent or not. A state is said to be recurrent if, once it has been reached, the 
IDS must be ready to transit again from it (possibly using another transition). In 
Fig.El node n2 is “nonrec” and node n3 is “rec” . Intuitively, n3 is a choice point 
(two arrows start from it), while n2 is not. How to determine if a node is recurrent 
or not is detailed in Sec. 14., 11 This distinction between recurrent and not recurrent 
states is the same as the one made between consuming and nonconsuming rules 
in STATE The existence of recurrent states in a SigGraph can also be 
compared to the duplication of tokens in IDIOT Petri nets jSj . 

Final states. A SigGraph actually contains only one final state. However, due 
to the existence of temporary final states during the construction of the graph. 
Final is defined as a subset of F. Final states are labeled by a fiag “accepF 
or “rejecF . This fiag is used to discriminate temporary final states during the 
construction; their precise meaning will be detailed in Sec. 14. 3L Figure does 
not contain any final state. 

Transitions. Transitions are labeled by a filter, a set SuchPred of predicates de- 
clared in such_that statements {SuchPred G P{Pred{S))) and a set ProcTrig 
of procedures declared in trigger statements {ProcTrig G V{Proc{S))). Given 
a transition, the predicates in SuchPred must hold to perform the transition; 
the procedures in ProcTrig are called when the transition is made. 

Labels “forwarT^ and “backward^ are used to discriminate transition types 
in the graph. Intuitively, “forward^ arrows correspond to a progress in the dis- 
covery of an instance. “Backward’ arrows correspond to a backtracking to a 
previous state in the graph because an instance of a negative part of an if_not 
is found. Figure El contains two “forward’ transitions from node nl. They re- 
spectively correspond to the detection of a link creation or a file reading by the 
same process as the one bound to variable P in node nl. Figure El also contains 
one “backward” transition which cancels the search if process P terminates. 

4.2 Generating Rules from a SigGraph 

This section sketches, on two examples, how a SigGraph can be used to generate 
rules for IDS. The two examples respectively use the rule-based languages of 
AS AX and P-BEST. 

Generating Russel Rules. Russel is the rule-based language of the ASAX 
system. An overview of this language can be found in [Zj, a more complete 
definition of the language with its semantics is proposed in HH. 

Briefly, a Russel program is a collection of rules where each rule consists of 
several “Condition — >■ Actions” statements. These rules can be parameterized 
by formal parameters. During the detection, ASAX handles a set of instances 
of these rules (ie. where formal parameters have been substituted by effective 
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Fig. 5. Excerpt of a SigGraph representing a Sutekh signature 



rule rl(int P) ; 
begin 
if 



( (event . ID=AUE_LINK) and (event . PID=P) and pred(event . Dbj )=true) 
— > begin 

trigger off for_next r2(P, event . Obj ) ; 
trigger off for_next rl(P); 
proc_alert 
end; 



) 



( (event . ID=AUE_QPEN) and (event . PID=P) ) 

— > begin 

trigger off for_next r3(P, event . Obj ) ; 
trigger off for_next rl(P); 
proc_alert 
end; 

( (event. ID=AUE_EXIT) and (event . PID=P) ) 

— > trigger off for_next rO; 

true 

— > trigger off for_next rl(P) 
fi 
end; 



Fig. 6. Russel rule generated from node nl of Fig.|S| 
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ones) called the “set of active rules”. Each time an event is generated by the 
audit, it is processed by each active rule. If the event satisfies one “condition” 
in a rule, the corresponding “action” is executed. The “action” part of a rule 
contains instructions which modify the set of active rules used to process the 
next event. 

Each node in the graph is transformed into a Russel rule. Figure EJshows the 
rule corresponding to node nl of Fig. 0 The BoundVars set of the node gives the 
number and the name of parameters of the rule. Rule rl has one parameter, P. 
All outgoing transitions from the node correspond to a “Condition — >■ Action” 
statement in the rule. 

The condition part of the statement is obtained by conjunction of (a) con- 
straints in the filter which used bound variables or constant values, and (b) 
predicates in SuchPred. Bound variables are replaced by the corresponding pa- 
rameters in the rule. Unbound variables are replaced by the audit field they are 
unified with. For example, in the first part of rule rl, variable P is bound, then 
event .PID is compared to parameter P; variable F is not bound, then predicate 
pred is evaluated with event . Ob j . 

The action part of the statement is obtained by (a) adding in the set of active 
rules for next event an instance of the rule corresponding to the successor of node 
nl through this transition (the trigger off statements in the example), and 
(b) calling procedures in ProcTrig. 

Finally, since the node is labeled “rec”, except if an event AUE_EXIT is de- 
tected, the rule always adds itself to the set of active rules for next event. 

Generating P-Best Rules. Production-Based Expert System Toolset (P- 
BEST) is a an expert system used, among others, in the EMERALD intrusion 
detection system US). A description of P-BEST capabilities can be found in m 

A P-BEST program consists of the definition of several fact types, and a set of 
inference rules on these facts. Inference rules are composed of two parts: the first 
part is a guard which tests the existence of facts satisfying logical expressions; 
the second part is composed of actions upon the fact base (adding, removing, 
modifying facts) and of calls to external functions. 

Figure 0 shows the rule corresponding to node nl of Fig.0 One fact type is 
created for each node in the graph. This is achieved by the ptype statements. 
Values stored in facts correspond to bound variables in the node. 

An inference rule is created for each transition in the graph. The guard of 
a rule tests the existence of a fact corresponding to the origin of the transition. 
In Fig. 0 all three rules test the existence of a fact x of type statel (in the 
[+x: statel] statement). Then, rules test if an event fact e satisfies the con- 

dition in the [? I < condition >] statements. The generation of the condition is 
similar to what has been done for the generation of Russel rules; here, bound 
variables are substituted by values stored in the fact x. 

If the event satisfies the condition, (a) the fact corresponding to the successor 
of node nl is created (for example, in rule rla, a fact state2 is created in the 
[+state2 . . .] statement), and (b) the procedures in the ProgTrig set are 
called ( [ ! I < call >] statement). 
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/* Declaration of one fact type 


per node */ 




ptype [ stateO ] 
ptype [ statel p:int] 
ptype [ state2 p:int, 






f : string] 






ptype [ States p:int, 






f : string] 






/* Definition of one rule per treinsition */ 




rule [rla] 


rule [rib] 


rule [rlc] 


[+x: statel] 


[+x: statel] 


[+x: statel] 


[+e : event] 


[+e : event] 


[+e : event] 


[? 1 e.ID == ^AUE_LINK. 


[? 1 e.ID == ’AUE_OPEN. 


[? 1 e.ID == ’AUE_EXIT. 


e.PID -- x.P, 


e.PID == x.P] 


e.PID -- x.P, 


’predCe . Qbj) == ’True] 






[+state2 1 p = x.P, 


C+stateS 1 p = x.P, 


[+stateO] 


f - e.Obj] 


f - e.Qbj] 


[-1 x] 


[! 1 proc_alert] 


[! 1 proc_alert] 





Fig. 7. P-BEST facts and rules generated from node nl in Fig. El 



If the node is labeled “rec” , the fact corresponding to the state is not removed 
from the fact base, except if the transition is ^‘backward\ In the example, rule 
rlc corresponds to a backward" transition, then fact x is removed ([-| x] 
statement). If the node is labeled “nonred\ the fact is always removed (not 
shown in the example). 

4.3 Building the Core Structure of a SigGraph 

Now that we know what can be done with the graph, let us go back to the 
algorithm to build it. The first step in the construction of the graph consists of 
creating its core structure (ie. the set of node F and the transition relation T). 

We define a function Q which builds the structure of the graph from Sutekh 
signatures. Q is inductively defined on the syntactic constructs of Sutekh. We 
present a definition of this function for each construct, and illustrate it on an 
example in Fig El In this figure, filters are only represented by letters (Ai, A2, 
B, C, D) since constraints in filters are not used in the definition of Q. 

Filter. The graph for a filter has two nodes, the first one is Init, the second 
one belongs to Final and is marked “accept” . BoundVars and ProcTrig of 
those two nodes are empty sets. Each node is marked nonrec (this is a default 
value which will possibly be modified later in the algorithm) . The transition 
between these nodes is labeled by the filter and marked “forward\ An 
example of such a graph is depicted in Fig. (jS^i) with the filter B in the 
right-hand side of the and. 

Choice (S = Si or 82). G{S) is obtained by merging Init states and merging 
final states of the two graphs. This operation is illustrated in Fig. (jS^i) by 
the graph corresponding to (Ai or A2) in the left-hand side of the and. 
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Interleaving (S = Si and 82 ). G{S) is obtained by performing the cartesian 
product of the two graphs. The Init state of 5(5) is the one corresponding to 
{Init{G{Si)), Init{G{S 2 ))); the final state of G{S) is the one corresponding 
to (Final{G{Si)), Final{G{S 2 )))- This operation is illustrated in Fig. (^) 
by the graph corresponding to ((^1 or A 2 ) and B). 

Sequence (S = Si then S 2 ). The Init state of the G{S) is the Init state of 
5(5i); its final state is the final state of 5 (^ 2 ). The Init state of 5(52) is 
merged with the final state of 5(5i). This operation is illustrated in the top 
of Fig. 0.b by the graph corresponding to (C then D), in the right-hand side 
of the if_not. 

Negation (S = Si ifmot S 2 ). Transforming an if_not is like transforming an 
and: the IDS must look in parallel for an instance of the positive part and 
an instance of the negative part of the if_not. However, if an instance of the 
negative part is found, the whole search must be cancelled. 

The transformation of if_not is split into four steps: 

— Step 1 : the cartesian product of 5(5i) and 5 ( 52 ) is computed. States 
resulting from the product of either Final{G{Si)) or Final{G{S 2 )) are 
final states of 5(5). Final states resulting from Final{G{Si)) are marked 
“accepF , those resulting from Final{G{S 2 )) are marked “rejecF . The 
node {Final{G{Si)), Final{G {S 2 ))) is marked '''' accept" . Indeed, in this 
case, even if an instance of the negative part of the signature is found, 
an instance of the positive one is found too. Labeling such states with 
“accept” is not an arbitrary decision, it means that recognition has pri- 
ority over cancellation. This is consistent with the semantics of Fig. 0 
— Step 2 : Since we are only interested in instances of S 2 after the first 
event of the instance of 5i (see semantics. Fig. all new transitions 
from the Init state which were not present in 5(5i) are suppressed. This 
makes some states unreachable: they are suppressed in turn. In Fig (|3 d), 
this operation removes one transition from Init, labeled by C, and leads 
to the suppression of two nodes (and eight transitions attached to them). 
— Step 3: All transitions after a final state are suppressed. As in previous 
steps, unreachable states are suppressed. In Fig &), this operation leads 
to the suppression of one node and five transitions. 

— Step 4: (a) all transitions to final states marked “reject" are replaced by 
“backward" transitions to the Init state, and (b) all final states marked 
“accept" are merged in a unique final state marked “accept" . 

such.that (S = Si such_that pred). 5(5) is obtained by adding, in all tran- 
sitions 5(5i), the predicate pred to SuchPred. This will be refined in the 
following. 

trigger (S = Si trigger proc). 5(5) is obtained by adding, in all transitions 
to final states of 5(5i), the procedure proc to ProcTrig. 



4.4 Static Analysis of Variable Binding in a SigGraph 

This section details how to compute the BoundVars set for each node of the 
graph. It is necessary to compute these sets because in a rule-based IDS, the first 
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Fig. 8. Building the core structure of the graph from Sutekh specifications 
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time a variable is encountered, it takes the value of the corresponding event field 
in the constraint; in all other constraints, using the variable generates a boolean 
test between the value stored in the variable and the event field. 

Due to disjunctions in signatures, several paths may lead to the same node 
in the graph. On these different paths, filters attached to transitions may not 
instantiate the same variables, and then, the set of bound variables in a node 
may differ according to the path which led to the node. 

The algorithm proposed in this section performs two tasks. Firstly, it com- 
putes the BoundVars set for each node. Secondly, each time it discovers that 
several BoundVars sets are possible according to the path that led to the node, 
it duplicates the node. After this duplication, for each node, the BoundVars set 
is unique for each path leading to it. 

Given a node n and a transition t, which connects node n' to node n, we 
define the set VarFrom(n, t) as: 

VarFrom{n,t) = BoundVars{n') U {Variables in equality constraints in t}. 
Namely, when transiting from one state to another, the bound variables in the 
destination states are those already bound in addition to those unified when 
matching the filter attached to the transition. 

Figure 0 shows an execution of the algorithm detailed later on in this section. 
In this figure, filters are abstracted by their name and variables used in equality 
constraints. In the “initial graph” of Fig. 0the VarFrom set related to node n2 
and transition C(X, Y) is: 

VarFrom(n2,C(X,Y)) = {}U{X,Y} = {X,Y} 

Definition 9. Given a node n, we define the relation of equivalence Tin over 
transitions with end connection in node n as: 

tiTint 2 VarFrom{nfii) = VarFromn{n,t 2 ) 

In the “initial graph” of Fig. 13 concerning node n2 only two transitions are 
in relation: A(X) 7^„2 B(X). Thus equivalence classes for node n2 are 
|{A(X),B(X)}, |C(X,Y)}} 

Algorithm. The algorithm of Fig EH uses the relation Tin to compute, for each 
node, (a) how many new nodes must be created (i.e. the number of equivalence 
classes), and (b) which transitions must be redirected to these new nodes. 

This algorithm is based on a “foreach” loop which does not specify any 
order. However, BoundVars sets must be computed in a precise order. This or- 
der is induced by dependencies in the definition of VarFrom and the calculus 
of BoundVars. BoundVars{n) depends on VarFrom{n, -). VarFrom{n, de- 
pends on BoundVars sets of predecessors of node n. Therefore BoundVarsfn) 
depends on BoundVars sets of the predecessors of node n. Since this algorithm 
does not consider “backward^ transitions, the graph is acyclic, and then such 
an order exists. 

Note that this algorithm does not use “Backward^ transitions. Indeed, when 
going backward in the search process, the set of instantiated variable does not 
grow. 
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Fig. 9. Example of computation of BoundVars sets in a SigGraph 



foreach node n do 

C = set of equivalence classes according to TZn 
foreach Ci £ C do 

Create a new node rii where: 

Incoming transitions to rii are those in a 
Outgoing transitions from m are those of n 
BoundVars(ni)-.=Varfrom(n,t) where t is a transition in a 
end -foreach 

Delete node n and all its incoming and outgoing transitions 

end foreach 



Fig. 10. An algorithm to compute BoundVars sets in a SigGraph 



In Fig. 0 after iteration “n = n2”, node n2 is duplicated into two nodes 
because BoundVars{n2) can be {X} for transitions A{X) or B{X), or it can 
be {X,Y} for transition C{X, Y). For a similar reason, node n3 is split. On the 
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opposite, node n4 is not duplicated since both paths from I nit to n4 lead to the 
same set of bound variables. Node n5 is not duplicated because there is only 
one incoming transition to this node. 

4.5 Taking Variable Instantiation into Account in a SigGraph 

BoundVars sets computed with the algorithm proposed in Sec. OI are used 
in the last step of the construction of the SigGraph. These sets permit (a) 
to “freeze” evaluation of non-evaluable constraints due to a lack of variable 
instantiation, (b) to refine the placement of predicates in SuchPred sets in 
transitions, and (c) to find recurrent and non-recurrent nodes. 

“Freezing” non-evaluable constraints. Consider the following signatures 
where f 1 and f2 are event fields, cl and c2 are constants and X is a variable: 
Si^ [ fl = cl, f2 != X ] then [ fl = c2, f2 = X ] 

S 2 = [ fl = cl, f2 != X ] and [ fl = c2, f2 = X ] 

In signature ^i, when an event E occurs, such that E(fl)=cl, variable X 
has no value, and the constraint “E(f2) != X” cannot be evaluated. When 
looking for an instance of S 2 , the same situation arises if an event El, such that 
El(fl)=cl, occurs before an event E2, such that E2(fl)=c2. These problems 
can be avoided by rewriting and S 2 as follows: 

Si^ [ fl = cl, f2 = X ] then [ fl = c2, f2 != X ] 

52 = ([ fl = cl, f2 = XI ] 

and [ fl = c2, f2 = X2 ]) such.that (X_l != X2) 

The initial expressions of both S\ and S 2 are correct Sutekh expressions with 
a natural declarative semantics. Using results of BoundVars set calculation, 
we automatically “freeze” constraints which are not evaluable, and delay their 
evaluation. 

For each transition in the SigGraph, if a constraint (I, r, v) cannot be eval- 
uated because v does not belong to BoundVars of the origin of the transition: 

— this constraint is transformed into “Z = Vnew" where Vnew is a new variable. 

— the variable Vnew is added to BoundVars sets of all nodes “posterior” to 
this transition. 

— the predicate ‘‘‘'Vnew f v" is added in SuchPred sets of all transitions “pos- 
terior” to this transition . 

This transformation of the SigGraph does not ensure that the new predicates 
added to SuchPred sets are evaluable where they are located. Refining the 
placement of SuchPred predicates is the purpose of the next item in this section. 



Refining placement of SuchPred predicates. Figure El shows a signature 
which combines sequence, interleaving, negation and such_that statements. The 
first graph in the figure results from the first two steps of the construction of the 
SigGraph (building the core structure and computing BoundVars sets). There 
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Fig. 11. Illustration of the last step of the SigGraph construction 



are six nodes with their corresponding BoundVars sets. Transitions are repre- 
sented together with their filter and SuchPred set {ProcTrig sets are omitted). 
Note that, during the construction of the core structure, the predicate P{X,Y) 
has been attached to all transitions under the scope of the such_that statement. 

Considering the first graph of Fig. (I I I h i two remarks can be done with re- 
spect to the predicates labeling the transitions: (a) P{X, Y) cannot be evaluated 
on transition (nl,n2) because Y is not bound in nl, and (b) since predicate 
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P{X, Y) has been evaluated to true on transition (n2, n3), evaluating this pred- 
icate on transition (n3,n5) is redundant. 



foreach transition t = (n,n') do 

foreach predicate P in SuchPredit) do 
Let V be the set of variables used in P 

If ( L ^ BoundVars{n')) then suppress P horn SuchPred{t) 
It {V C BoundVars{n)) then suppress P from SuchPred{t) 

end_foreach 
end foreach 



Fig. 12. An algorithm to delay non-evaluable predicates and remove redundant ones 



The algorithm of Fig II 21 removes both non-evaluable and redundant predi- 
cates. The test ( V ^ BoundVars(n') ) removes the predicate P if not enough 
information are available to evaluate P. In Fig. m this concerns P{X, Y) on the 
transitions (nl,n2), (n2, n4), and (n4,n2). The test (V C BoundVars{n)) 
removes the predicate P if there were enough information to evaluate P before 
performing this transition. In this case P has been evaluated before reaching the 
origin state of the transition. In Fig. this concerns P{X, Y) on the transitions 
(n3,n2) and (n3,n5). 



Finding recurrent and non-recurrent states. A state is marked “nonred^ if 
and only if it has at most one outgoing “forward^ transition and its BoundVars 
set is equal to the one of its successor through this transition. A state is marked 
“rec” in all others cases. Intuitively, this means that a state is said to be 
“recurrent” if, when transiting from this state, the IDS must be ready to detect 
another event which leads either to an other path in the graph, or to the same 
path with different variable instantiations. 

This is shown in Fig. Ill Il iV Node n2 is recurrent: there exists two “forward” 
transitions (B{X) and C{Y)) from this node. Nodes nl and n4 are recurrent: 
transiting from both these nodes add variables in BoundVars sets. Nodes n3 
and u5 are non-recurrent: only one “forward^ transition starts from each node, 
and transiting through it does not bind more variables. Node u6 is non-recurrent 
since it has no successor. 

5 Related Work 

Sutekh provides a combination of functionalities at least as complete as the union 
of what is offered by the following declarative systems. Our chain of transfor- 
mations from declarative signature specifications to operational rules gives an 
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operational semantics to the declarative signatures independently of a given im- 
plementation. 

Chakravarthy et al. define in P| the semantics of Snoop, a composite event 
language in the context of active databases. The semantics of Sutekh extends 
the semantics of Snoop with logical variables to correlate events. 

Lin et al. define MuSigs nn. a declarative signature language, as part of the 
ARMD project. In MuSigs, signatures are specified by a direct acyclic graph 
(DAG) where nodes are labeled with logical predicates describing constraints 
on events. The DAG structure allows temporal relations between events to be 
specified; variables in predicates express event correlation as in Sutekh. However, 
signatures in MuSigs cannot easily specify nested disjunctions, and we do not 
see any means to specify the equivalent of our if_not. Furthermore, the authors 
propose an iterative algorithm to look for instances of MuSigs signatures, but 
no details are given about the critical treatment of variable binding. 

Gerard describes in jSj LaDAA, a declarative language where “simple condi- 
tions” (similar to Sutekh filters) are combined using sequence, disjunction and 
conjunction operators. Sutekh extends LaDAA by adding the if_not and the 
such.that constructs. The construction of the core structure of the SigGraph 
is inspired by the algorithm proposed in |0| to generate Russel rules for ASAX. 
Our algorithm, however, goes further with its static analysis of variable binding. 

LAMBDA, presented by Guppens and Ortalo 0, and ADeLe, proposed by 
Michel and Me ^3] are two languages providing frameworks to describe sce- 
narios of attacks together with their conditions of execution, their impacts on 
the target system and their signatures. Fragments of these languages are ded- 
icated to signature description. Sutekh can be seen as the union of these two 
fragments. Furthermore, we are not aware of an operational semantics of these 
two languages. 



6 Conclusion 

In this article we have described Sutekh, a declarative signature specification 
language, and have presented its semantics. We have also shown how to produce 
operational detection rules from declarative signatures. A number of technical 
problems, which must be meticulously considered when writing state-transition 
diagrams, have also been exhibited. In particular, partial order, together with 
negation and logical variables, can lead to instantiation problems. We have solved 
these problems by a static analysis of the evolution of variable binding during 
the detection. This analysis could also be done by hand in low-level specifications 
but it would be prone to mistakes. Our automated processes limits such risks 
and is well suited to further develop performance improvements. 
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Abstract. This paper describes a new approach to collecting real-time 
transaction information from a server application and forwarding 
the data to an intrusion detection system. While the few existing 
application-based intrusion detection systems tend to read log files, the 
proposed application-integrated approach uses a module coupled with 
the application to extract the desired information. The paper describes 
the advantages of this approach in general, and how it complements 
traditional network-based and host-based data collection methods. The 
most compelling benefit is the ability to monitor transactions that 
are encrypted when transported to the application and therefore not 
visible to network traffic monitors. Further benefits include full insight 
into how the application interprets the transaction, and data collection 
that is independent of network line speed. To evaluate the proposed 
approach, we designed and implemented a data-collection module for 
the Apache Web server. Our experiments showed that the required 
implementation effort was moderate, that existing communication and 
analysis components could be used without incurring adaptation costs, 
and that the performance impact on the Web server is tolerable. 

Keywords: Intrusion detection, application, application-integrated, 
module, Web server, Apache. 



1 Introduction 

Intrusion detection systems (IDSs) can be categorized with respect to several 
different dimensions, of which the commonly used (but somewhat oversimplified) 
dichotomy between misuse detection and anomaly detection is one example. 
Another dimension for categorization is the type of event data analyzed by the 
IDS. An IDS that monitors traffic flowing in a network is usually called network 
based, while an IDS that analyzes data produced locally at a host is often referred 
to as host based. 

* The work described here is currently funded by DARPA/ATO under contract num- 
ber F30602-99-C-1049 and contract number F30602-98-C-0059. The views herein 
are those of the author(s) and do not necessarily reflect the views of the supporting 
agency. 



W. Lee, L. Me, and A. Wespi (Eds.): RAID 2001, LNCS 2212, pp. 22-^^ 2001. 
@ Springer- Verlag Berlin Heidelberg 2001 



Application-Integrated Data Collection for Security Monitoring 



23 



We subdivide the host-based category further, depending on the abstraction 
level at which data is collected. Most existing host-based systems gather audit 
data at the operating system (OS) system-call level, but an IDS could get its 
data from higher as well as lower abstraction levels. Below the OS level, we 
could, for example, look at the executed processor instructions. Above the OS 
level, we could collect data from service applications such as database manage- 
ment systems, Web servers or e-mail daemons, or from end-user applications. As 
different types of security violations manifest themselves on different levels in a 
system, one could argue that it is important for the IDS to collect data at the 
most meaningful abstraction level(s) for the event in question. It should be kept 
in mind that independent of the type of data collected, it can be sent to any 
type of analysis engine (e.g., signature based, model based, probabilistic). 

In this paper, we focus on collection of data produced by applications (above 
the OS level) and refer to an IDS analyzing such data as application based. Al- 
though the concept of application-based IDS is not new, there is a striking ab- 
sence of commercial IDSs for applications other than firewalls jS|. The approach 
presented in this paper shows how the data collection for an application-based 
IDS can be integrated with the monitored application. 

The remainder of this paper is organized as follows. Section O discusses lim- 
itations of network-based and host-based IDSs, respectively. In Section E| we 
present our application-integrated approach, and discuss its advantages and how 
it complements the other methods. Sectional describes an implementation for a 
Web server to validate our reasoning. In Section 0 we examine the performance 
characteristics of the implementation. Section 0 describes related work, while 
ideas for future work are outlined in Section 0 Our conclusions are summarized 
in Section 0 

2 Background 

Many researchers have recognized that there is no single “silver bullet” ap- 
proach to automatic detection of security violations. By combining and inte- 
grating complementary approaches, better attack space coverage and accuracy 
can be achieved. In this section, we look at some specific problems with the 
network-based and host-based approaches, respectively. 



2.1 Network-Based Data Collection 

The popularity of Ethernet technology paved the way for network-based IDSs. 
When traditional broadcast Ethernet is used, a whole cluster of computers can 
be monitored from a dedicated machine that listens to all the traffic. As no 
changes in the infrastructure are required, and there is no performance penalty, 
most free and commercial IDSs use this approach. The system can be completely 
hidden by having a network card that listens to the network but never transmits 
any traffic itself. However, by decoupling the system from the actual hosts it 
supervises, we lose valuable information. 
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First, probably the most serious problem with the network-based approach 
is encrypted traffic, which in effect makes the network monitor blind to many 
attacks. Today, encryption is typically used to protect the most sensitive data, 
and there are indications that encryption will become more ubiquitous in the 
near future, making today’s network-based monitors ineffective^ 

Second, the IDS can be deceived in several ways. Most Internet standards 
in the form of RFCs carefully define valid protocol syntax, but do not describe 
in detail how the application should behave with deviant data. To be accu- 
rate, the IDS needs to model how the application interprets the operations, but 
this is almost an impossible task without receiving feedback from the applica- 
tion. Minor differences in operations play a major role in how they are inter- 
preted. For example, consider a user requesting a certain Web page, by sending 
http : //www . someHost . com/dirl\f ilel (note the backslash character). If the 
receiving Web server is Microsoft-IIS/5.0 under Microsoft Windows, the server 
looks for the file filel in the directory dirl. However, if the server is Apache 
version 1.3.6 under Unix, the server looks for a file named dirl\f ilel in the root 
directory. Even if an IDS could model the different popular servers, it cannot 
account for every implementation difference in every version of these. This prob- 
lem is not limited to application-level protocols, but as Ptacek and Newsham 0 
describe, the same goes for lower-level protocols. 

Third, efforts to increase bandwidth in networks pose serious problems for 
network-based IDSs. Higher line speed is in itself a difficulty, and switching 
(unicast) technology ruins the possibility to monitor multiple hosts from a sin- 
gle listening point. Some IDS developers try to address this problem by placing 
a network data collection unit on every host. That solves this problem while in- 
troducing others, which are similar to the problems faced by host-based analysis. 

2.2 Host-Based Data Collection 

The host-based approach addresses some of the problems described above, with 
the primary advantage being access to other types of information. As it is in- 
stalled on a host, it can monitor system resources as well as look at operating 
system audit trails or application logs. It is also independent of the network 
speed as it monitors only a single host. However, the system administrator now 
needs to install a number of monitors instead of just one, thus incurring more 
administrative overhead. Also, the user could experience a performance penalty 
as the monitor is on the same host as the application. 

Furthermore, most monitors on the OS level cannot detect attacks directed 
at the lower network protocol levels because network information typically does 

^ There are some ways a network-based IDS could read encrypted traffic. For example, 
it could act as a proxy with the encrypted channel being only to the IDS (or a similar 
proxy), thus introducing unnecessary overhead in the form of extra programs that 
need to be supervised and also exposure of data before it reaches its final destination. 
The network monitor can also be given the private key of the server, increasing the 
exposure of the key and forcing the network monitor to be able to keep track of user 
sessions and their associated keys. 
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not become available in the audit event stream until it has reached the higher 
protocol levels. See m for an approach to include network data in OS audit 
data. 

An application-based monitor in the traditional sense (such as the one de- 
scribed in P) reads data from log files or other similar sources. By the time the 
information is written to the log, the application has completed the operation in 
question and thus this monitor cannot be preemptive. The information available 
is often also limited to a summary of the last transaction. For example, a Web 
request in the Common Logfile Format (CLF) is 

10.0.1.2 - - [02/Jun/1999:13:41:37 -0700] "GET /a.html HTTP/1.0" 404 194 

Without going into the meaning of the different fields, the following recounts 
the scenario: The host with address 10.0.1.2 asked for the document a.html, 
which at that time did not exist. The server sent back a response containing 194 
bytes. 

The log entry does not contain all the information an IDS needs for its 
analysis. Were the headers too long or otherwise malformed? How long did it 
take to process the request? How did the server parse the request? What local 
file did the request get translated into? 

In some applications, logging can be customized and contain much more 
information. Nevertheless, we have not yet seen a system where all internal 
information needed to understand the interpretation of an operation is available 
for logging. Furthermore, by turning on all log facilities, we increase the risk of 
running out of storage space for the logs and incurring performance degradation. 



3 Application-Integrated Data Collection 

As we have shown in the previous section, there are problems associated with 
both network-based and host-based approaches. Some of these can be solved 
by collecting data directly from the single critical application that we want to 
monitor. In this section, we present the general principles of this approach, while 
Section El describes a prototype implementation for monitoring Web servers. 



3.1 Rationale 

Today’s network structure within organizations makes a few applications critical. 
These need to be available around the clock from the outside of the organization; 
they are sensitive to attacks but seldom sufficiently protected. Examples include 
Web servers, e-mail servers, FTP servers, and database systems. 

To minimize security concerns, most such critical applications run on dedi- 
cated machines and are protected by firewalls. Typically, no other application is 
running on these machines. If remote login is allowed, it is very restricted (such 
as only ssh) . Thus, the malicious user must go through the channels of the critical 
application to subvert the host. By having the IDS monitor the inner workings 
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of the application, analyzing the data at the same time as the application inter- 
prets it, we have a chance of detecting malicious operations and perhaps even 
stopping them before their execution. However, for us to successfully integrate a 
monitor into the application, the application must provide an interface. Some ap- 
plications provide an API and, as the advantage with an application-integrated 
monitor becomes clear, we hope that more vendors will provide such interfaces. 
Other venues for integration are found in the open-source movement. 

3.2 Advantages 

Access to unencrypted information. In almost all cases, data must be ac- 
cessible inside the application in unencrypted form for meaningful processing, 
even if it is encrypted in lower layers. Consequently, the unencrypted data is also 
accessible to an application-integrated data collection module. This is a major 
advantage compared to a network-based IDS. Moreover, it should be noted that 
because encryption is used for the most sensitive data, the functions handling 
that data are probably among the most interesting from an attacker’s point of 
view and therefore important to monitor. 

Network speed is not an issue. The module is part of the application, and 
takes part in the normal processing cycle when analyzing operations. Thus, the 
limiting factor is the application speed rather than the network speed. For ex- 
ample, if the original application can accept a certain number of connections 
per second, the application equipped with the module must be able to perform 
equally well. Care must be taken so that the module does not become a bot- 
tleneck and does not consume too many of the host’s resources. We discuss our 
solution to this problem in detail in the next section. 

More information available. Being part of the application, the module can 
access local information that is never written to a log file, including interme- 
diate results when interpreting operations. It can monitor how long it takes to 
execute a specific operation, to detect possible denial-of-service (DoS) attacks. 
Furthermore, we expect an application-integrated monitor to generate fewer false 
alarms, as it does not have to guess the interpretation and outcomes of malicious 
operations. For example, a module in a Web server can see the entire HTTP re- 
quest, including headers. It knows which file within the local file system the 
request was mapped to, and even without parsing the configuration file of the 
Web server, it can determine if this file will be handled as a CGI program (not 
otherwise visible in either network traffic or log files). 

True session reconstruction. Information of interest to an IDS often concerns 
transactions (request-response) and user sessions. To extract that information, 
a network-based monitor must perform expensive reconstruction of transactions 
and sessions from single network packets, and it is still not guaranteed to cor- 
rectly mimic the end-point reconstruction. In contrast, the application-integrated 
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module is handed complete transaction and session records directly from the ap- 
plication, and there is consequently no discrepancy between the interpretations. 



The IDS could be preemptive. IDSs are at times criticized for being of 
limited use as they can only report intrusions, usually too late to stop any 
damage. By being part of the application, the module could supervise all steps 
of the processing cycle and could react at any time. For example, it could deny a 
single operation that appears malicious without otherwise compromising server 
performance. 

3.3 Disadvantages 

The disadvantages of the application-integrated monitor coincide with some of 
the disadvantages of the host-based monitors in general, as described in Sec- 
tion O 

Any monitoring process running on the same host as the monitored service 
risks to impact the performance of the server. It is therefore important that a 
goal in the monitor design and implementation is to minimize this performance 
impact. 

Given that one needs to have a distinct application-integrated monitor for 
every single type of application one wants to monitor, the development efforts 
could be significant. However, in today’s situation where a handful of products 
dominate the field of network server applications, the efforts and costs required 
for a satisfactory coverage could be lower than they might first appear. This is 
particularly true for applications that are open source and/or provide an API 
for modules. 

The application-integrated monitor can only be a complement to other types 
of IDSs. As it is part of the application, it sees only the data reaching the ap- 
plication. By targeting a protocol below the application layer, an attacker could 
evade detection by our module, but would be within the scope of a network-based 
IDS or possibly another host-based sensor specialized in lower-level protocols. 

4 Design Principles and Implementation 

As discussed in the previous section, current network infrastructure makes a 
few applications critical. Of these, the Web server stands out as being both 
ubiquitous and vulnerable. First, most organizations need a Web server, and 
it is the service most users associate with the Internet. Second, even though 
the server software might be as stable (or unstable) as other types of software, 
many sites have customized programs connected to the server allowing access 
to legacy database systems. Because these programs are easy to write, they 
are often developed by junior programmers who do not properly consider the 
security aspects of letting any user in the world supply any input to programs 
run locally. As a result, new vulnerabilities in CGI programs are discovered 
daily. Furthermore, the Web server is among the first to be probed during a 
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reconnaissance. The vulnerabilities are easy to comprehend (e.g., add a semicolon 
after the request in your browser), and the gratification is instant (change the 
Web pages and all your friends can admire your deed). 

For these reasons, we chose to focus our prototype on a Web server. The 
major Web server brands also have an API which provides the capabilities we 
desire for application-integrated event data collection. The remaining question 
is which server product to target. 

Netcraft continuously conducts a survey of Web servers on the Internet j2|. 
Some results from the February 2001 survey are shown in Table Q It shows that 
there are three main players in the market covering more than 85%. We decided 
to build our first application-integrated data collection module for the Apache 
Web server, as it is the most popular one. 



Table 1. Market shares for the top Web server products 0 



Product 


Developer 


Market Share 


Apache 


Apache 


60.0% 


Microsoft-IIS 


Microsoft 


19.6% 


Netscape-Enterprise 


iPlanet 


6.2% 



The market penetration for SSL is very different. Unfortunately, the data 
is considered commercially valuable and is available as a commodity only for 
a prohibitively high price. Furthermore, the Netcraft survey counts each site 
equally. This reflects neither the popularity of the site nor the risk and associated 
cost of attacks. We are not aware of any other survey of this kind, and even if 
the numbers above are subject to discussion, there is no doubt that Apache has 
a large share of the market. 



4.1 Implementation 

As it turns out, it is quite easy to extend the Apache server with our data 
collection module, primarily due to the following reasons. 

— There is a well-defined API for modules and the data concerning each request 
is clearly distinguishable in distinctive data structures. 

— Each request is processed in several stages, and there are so-called hooks or 
callbacks in each of these stages that a module can use (see Fig. QJ. 

— After each stage, the module can give feedback to the server as to whether 
it should continue executing the request. 

— There is support for extensive logging capabilities through the reliable piped 
logs interface (explained below). 
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Fig. 1. The Apache request loop m- The solid lines show the main transaction path, 
while the dashed lines show the paths that are followed when an error is returned 




Fig. 2. The architecture and data flow in the implementation 
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We built the module within the framework of EMERALD |H| , which among 
other components include the eXpert-HTTP analysis engine and the eFunnel 
communications process described below. The layout of our system is depicted 
in Fig. 0 For each request, the following happens: 

1. The Web server passes control to our module in the logging stage of the 
request cycle. 

2. The module takes relevant data of the request and packs it into a format the 
analysis engine eXpert-HTTP can understand. 

3. Through the reliable piped logs interface of Apache, we pass the informa- 
tion to an auxiliary program, which just hands the information to a second 
program, eFunnel, through a socket. 

4. eFunnel, in turn, communicates with an eXpert-HTTP on an external host. 

5. The eXpert-HTTP performs the analysis. 

Below we discuss each of these steps in detail. The design reflects mainly three 
concerns. Most importantly, we do not want to introduce vulnerabilities into the 
server software. For this reason, we decided to keep as little code as possible 
within the server. The second issue is performance. If the module makes the 
server slow, it will not be used. By limiting the analysis on the server host, we 
gain speed but we lose interactivity between the module and the server. Third, 
we wanted to reuse as much code as possible, both in the server and from the 
EMERALD system. 

As our major concern was the risk of introducing vulnerabilities into the 
server, we decided against letting the analysis engine be part of the server. 
This would have added a lot of extra code, thus increasing the complexity and 
making the server more vulnerable to bugs |3 Theorem 1] . Although the analysis 
engine could have been placed on the same host, we wanted to demonstrate that 
larger sites can use this approach and satisfy critical performance requirements. 
However, removing the analysis engine from the server in turn means we limit 
the preemptive capabilities we described in Section 0 as the distance introduces 
latency between the receiving of a request and the final analysis. In Section 0 we 
propose a two-tier architecture that offers an acceptable trade-off between the 
ability to react in real time while still minimizing performance penalties. Note 
that the setup with the server existing on a separate host is more complicated 
than having the analysis engine on the same host. On sites where performance 
is not of critical importance, we recommend the simpler approach. 

The introduced latency described in the previous paragraph restricts the 
reactive capabilities of the module. For this reason, we decided to let our module 
be called only in the last step of the request cycle — the logging step. By this time, 
the server has interpreted the request and sent the data to the client, and all 
information about the request is available for logging, which makes it easy for 
our module to extract it. Even though this seems to be marginally better than 
a system reading log flies, we would like to point out two advantages with our 
proposed application-integrated module. 

First, we have access to more information. For example, consider the request 
http://www.w3c.org/phf. The application-integrated monitor can determine if 
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the server will handle the request as a CGI script (possibly bad), or if it ac- 
cesses an HTML file (that, for example, describes the phf attack). Second, the 
information is immediately available with the application-integrated approach. 
A monitor watching a log file must wait for the application to write the informa- 
tion to the file, the caching within the operating system, and possibly the next 
monitor polling time. 

The last steps of our design are explained by considering code reuse. Within 
the EMERALD framework, we have a component called eFunnel. This program 
accepts incoming connections where EMERALD messages can be transmitted, 
and passes the information to outgoing connections. It can duplicate incoming 
information (e.g., having two different analysis engines for the same application) 
or multiplex several incoming flows into one outgoing connection (e.g., comparing 
the results of a network-based monitor with an application-integrated monitor 
for discrepancies) . This program takes into account problems that might appear 
in interprocess communication, such as lost connections or necessary buffering. 
Thus, eFunnel exactly matches our needs to send information from the module 
to other components. 

On the server side, Apache provides a reliable pipe log interface. This inter- 
face sends the log information directly to a program. The term reliable signifies 
that Apache does some checking on the opened channel, such as making sure 
the connection is still accepting data. If that is not the case, it restarts the 
program fI2| p. 563]. We also hope to capitalize on future advances within the 
implementation of this interface. 

As noted, we would like to use both eFunnel and Apache’s “reliable log 
format” but we run into a practical problem. In our tests, Apache started the 
receiving program twice El p. 59], but eFunnel binds to certain predefined 
sockets locally, and can thus be started only once. Our solution involves the 
auxiliary program described in Step 3 above, which provides a clear interface 
between the Web server and the IDS. Apache can restart this program as often 
as necessary, without the IDS being affected. 



4.2 Analysis Engine 

Within EMERALD, we are developing a package of network-based IDS com- 
ponents, one of them being eXpert-HTTP, an analysis component for HTTP 
traffic. It was developed to receive event messages from the network data col- 
lection component etcpgen, but can equally well receive the messages from the 
application-integrated module. Actually, we can use exactly the same knowledge 
base independent of the source of the data and no additional development cost 
is necessary for the analysis engine. After we had completed the data collection 
module, we could directly test it by having it send the data to eXpert-HTTP. It 
is not surprising that as more information is available through the module than 
through network sniffing, we have the possibility of constructing new rules to 
detect more attacks as well as refining existing rules to produce more accurate 
results. 
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4.3 Summary 

Basically, our module extracts all transaction information from the Web server 
and packs it into a format that the analysis engine can understand. The module 
then ships off the information (through multiple steps due to the aforementioned 
implementation issues) to the analysis engine located at a separate host. No 
changes to the analysis engine were necessary even for detection of attacks using 
the encrypted SSL channel, so the module and the network-based event data 
collector could be used interchangeably with the same knowledge base. If we 
want to capitalize on the extra information we gain by using the module, we 
obviously need to develop new detection rules. 

5 Monitor Performance 

From a performance standpoint, the application-integrated module does not do 
anything computationally intensive. It simply accesses a few variables and for- 
mats the information before it is sent on. This should not decrease the server 
performance. However, we would like to have a more substantial claim that our 
approach is viable. One way would be to let the module include a call to a timing 
function (in C) to show how much execution time is spent inside the module. We 
decided against this measure, as we are more interested in measuring the user 
experience when an entire monitor is running. This means that we configured 
the module to send the data to the eXpert-HTTP analysis engine on another 
host, as depicted in Fig. El 

WebLoad from RadView Software is an advanced Web application testing 
and analysis package mg. Among its many features and options, it allows us to 
specify a single URL that will be continuously fetched during a specified time 
interval. WebLoad measures the round-trip time for each transaction, giving a 
fair measure of the user experience with the network and the server. We used 
the free evaluation version of WebLoad, which has some restrictions compared 
to the full-blown commercial version. However, those restrictions (no support for 
SSL and a maximum of 12 virtual clients) did not significantly limit our ability 
to evaluate the performance of our module. 

We set up four runs, each lasting 60 minutes and using 10 virtual clients 
on a single physical client host. We used two different types of URLs, the first 
returning a Web page consisting of about 50 KB of text and a 12 KB JPEG 
image, while the second caused the execution of a CGI program. A summary 
of the results is in Table 0 The absolute values may seem somewhat high, but 
are due to the relatively low-end server hardware configuration. The relative 
difference between running the monitor or not is so small that it is probably 
only caused by the CPU load imposed by the auxiliary communications process 
and eFunnel running in parallel with the Web server. In fact, we believe that 
the results confirm that a future application-integrated module can have zero 
performance impact (with respect to response time) on the Apache application, 
as explained below. 

In Fig. 0 we show the request cycle for the server. The module performs 
logging after the request has been sent back to the client. For this reason, we 
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Table 2. Performance measurements 



Round-trip 

time 

(seconds) 


Page 

without 

monitor 


Page 

with 

monitor 


Impact 


CGI 

without 

monitor 


CGI 

with 

monitor 


Impact 


median 


1.486 


1.517 


2.1% 


1.192 


1.229 


3.1% 


average 


1.499 


1.521 


1.5% 


1.195 


1.238 


3.6% 


std. deviation 


0.057 


0.059 




0.034 


0.048 





expect that it is possible to postpone the penalty of the module until the next 
request. In Fig. 01 we show details of a possible scenario of what could happen 
in the server. The server spawns several child processes to handle new requests. 
As long as there are enough children, the penalty of the module does not need 
to be noticeable, as a child can finish logging before it receives the next request 
to handle. Under heavy load, where a request would have to wait for logging of 
the previous request, this would of course be different. 

Apache/ 1.3. 6 behaves in a different way from what is depicted in Fig. 0 
Depending on the content sent back to the client, we observed a different behav- 
ior. We suspect that this depends on different implementations of the so-called 
Content-Handlers m- 



request response 

\ i 



i 




Fig. 3. Details of a possible scenario for Web server request handling. The numbers 
denote parallel processes ready to serve a new request 



We did not stress test the Web server in the measurements described above, 
for two reasons. First, we have measured the whole system and we cannot at- 
tribute the difference in time to any specific reason. A stress test also affects the 
server and the operating system, neither of which is under investigation in this 
article. Second, we believe that many commercial server parks are built for peak 
needs and are therefore normally underutilized. 
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6 Related Work 

The concept of application-based IDSs is not new, and there are indications 
that this would be the next big field to explore for commercial IDS vendors. 
There are some IDSs that are capable of monitoring firewalls p]. In contrast, 
we are currently aware of only one single example of a commercial Web server 
IDS, AppShield from Sanctum, Inc. It is a proxy that overlooks the HTML 
pages sent out. For example, it scans HTML forms sent from the server, and 
makes sure that the information returned is valid (e.g., allows the use of hidden 
fields) . Even though it actively monitors the Web server, it is not integrated into 
a greater IDS framework. 

The closest to our approach is the work done by Burak Dayioglu 0. His 
module simply matches the current request with a list of known vulnerable CGI 
programs. As the analysis is performed in line with the data collection, there is 
a greater risk of reduced server performance, especially if the list grows large. 



7 Improvements 

The module prototype described in this paper is the first step in the explo- 
ration of the possibilities of application-integrated data collection for IDS. By 
extending the knowledge base of the IDS to fully utilize the information available 
through the module, we hope to improve detection rates and reduce false-alarm 
rates. A natural step is also to develop similar data collection modules for other 
server applications, such as FTP, e-mail, databases, and Web servers other than 
Apache. We already have a working prototype for the iPlanet Web server. 

It could also be interesting to have an analysis engine compare the transaction 
data from the application-integrated module with data from network sniffing. 
The subset of data items that is available to both collectors should normally be 
identical, except when someone actively tries to fool one of the collectors. This 
could potentially enable detection of advanced attacks that try to circumvent 
the IDS. 

In Section 0 we described the trade-off between preemptive capabilities (ap- 
plication-integrated analysis) and low performance impact (application-integrat- 
ed data collection but external analysis). We could have a two-tier architecture 
where the application-integrated module performs a quick and simple analysis 
before the request is granted by the application and then passes the data on 
to an external advanced analysis engine. If the first analysis detects an attack 
attempt, it could cause the request to be denied. The second analysis could also 
pass feedback to the first, such as the name of a host that has launched an attack 
and should not be serviced again. Instead of outright denying the request, the 
application-integrated module could suspend a request it finds suspicious until 
the external analysis engine has reached a conclusion. By tuning the first filter, 
we could restrict the performance penalty to a small subset of all requests, but 
still be able to thwart attacks. 
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8 Conclusions 

We have presented an application-integrated approach to data collection for 
intrusion detection. By being very specialized, the module is closely tailored to 
be part of the application and have access to more information than external 
monitors, thus being able to discover more attacks but also to reduce the number 
of false alarms. Because each module is specific to one application product, 
coverage of many products could lead to an increased development cost, but we 
showed several reasons why that is not a severe limitation of this approach. 

If this approach becomes popular, we expect vendors to provide an API for 
similar products in the future to stay competitive. This means very little extra 
effort is needed to include this type of monitor in a component-based IDS, such as 
EMERALD. We also showed the advantages with our prototype for the Apache 
Web server. It gave us access to information internal to the server, which helped 
the IDS understand how the server actually parsed the request. The module had 
access to the decrypted request, even if it was transported through SSL over the 
wire. As we clearly separated the data collection from the analysis engine, the 
performance penalty was negligible. The knowledge base could be used with no 
change, thus leveraging previous investments. 

Acknowledgments. Phillip Porras and Steven Dawson of SRI International 
made an early prototype design and implementation of a transaction-data col- 
lection module for Apache. Their work served as an example and inspiration 
upon which we based the implementation presented in this paper. 
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Abstract. In this paper we describe an interface between intrusion de- 
tection systems and trusted system components. The approach presented 
differs from conventional intrusion detection systems which are only 
loosely coupled to the components which they protect. We argue that 
a tighter coupling makes an IDS less vulnerable to desynchronization at- 
tacks, furnishes it with higher quality information and makes immediate 
and more fine grained responses feasible. Preliminary results show that 
this can be achieved through an external, nonspecific, voluntary refer- 
ence monitor accessible to applications through a simple API. Reasonable 
performance can be maintained by moving most of the IDS functionality 
into the context of the trusted application. 



1 Introduction 

Conventional intrusion detection systems passively intercept traffic between the 
entities they guard and potential attackers. Such a mechanism is vulnerable to 
desynchronization attacks and only offers a coarse, indirect response. 

We propose a direct coupling between application and IDS. The IDS assumes 
the role of an external, voluntary reference monitor which the application pro- 
grammer can consult for a second opinion whenever an action is taken which 
has an impact on security. 

Making the IDS visible to an application programmer incurs an initial ex- 
pense, but has the advantages of being difficult to desynchronize or bypass, and 
allows fine grained preventative measures, as opposed to indirect responses. 

Our system is primarily intended for services and applications which have 
some security function and need to defend themselves against subversion — 
trusted applications in our terminology. 

The next section motivates the need for access control at the application level, 
section 0 sets out the methods which can be used to monitor applications and 
section El introduces instrumentation methods. Section 0 motivates the need for 
a targeted response, sectional sets out the direct IDS to application coupling and 
sectionQour implementation of this interface, IDS/A. Applications, usage and 
brief results are described in sections and cni Limitations of our approach 
are discussed in section im and we finish with a section on related work and a 
conclusion. 



W. Lee, L. Me, and A. Wespi (Eds.): RAID 2001, LNCS 2212, pp. 37-^^ 2001. 
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2 Trusted Applications 

For this paper we shall define a trusted application as a user space program which 
is intended to interact with more than one protection domain, while a trusting 
application is defined as one which operates inside a single protection domain. We 
use the term application in the widest sense, web servers and database managers 
are included in our definition. 

Whenever an application interacts with more than one protection domain, it 
becomes interesting to attackers as a subverted application can then be used to 
cross into a domain previously inaccessible. Conversely, an application restricted 
to one protection domain is of limited interest to an attacker, as subverting it 
yields no new rights. 





Trusted Application Trusting Application 

Fig. 1. Trusted applications (such as a database) straddle domains and need to control 
exchanges across domains, while trusting applications (such as an interactive command 
interpreter) are contained within a single domain 



Like an operating system, a trusted application has to enforce access policies 
and resist subversion. However, while the operating system reference monitors 
have been reasonably well studied, less attention has been devoted to the access 
control decisions which are made at the application level. 

Assuming that the need for trusted applications will disappear if only conven- 
tional operating systems were to provide sufficiently fine grained access controls 
is ill-advised: Consider the example of a trusted medical database application 
which allows a user to compute the percentage of individuals suffering from a 
given disease, but not to retrieve the disease status of an individual. Differenti- 
ating reliably between these two queries can not be done by the host operating 
system unless it duplicates the database logic. 

It is probable that trusted applications will become more significant in the 
future, as systems tend to become ever more connected and nested, resulting 
in component-based applications and distributed applets which are expected 
to interact seamlessly across protection domains. In many cases applications 
provide their own execution environments (e.g. java virtual machines, database 
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stored procedures, macro interpreters for word processors) making it possible to 
nest applications one inside the other (e.g. a java-based tax calculator running 
inside web browser). In such situations the underlying operating system access 
controls have little relevance. 



3 Application Monitoring 

Given that applications will remain vulnerable to subversion, it is prudent to 
monitor applications for signs of failure. This is the field of intrusion detection, 
with a focus on individual applications as opposed to the more common network 
intrusion detection. 

An application can be monitored by one of three methods: 

Interception : Interception involves decoding the exchanges between the mon- 
itored application and other parties by the IDS itself. Interception is trans- 
parent to both the application and its peers. Most network-based intrusion 
detection systems make use of this method. 

Instrumentation of a third party : This approach uses audit or log mes- 
sages from a party other than the monitored application. It differs from 
interception in that the third party, not the IDS, is responsible for decoding 
messages emitted by the application, and that the third party is visible to 
the application. An example of such a system would be the application layer 
proxies of TIS’s firewall toolkit m or the audit trail of an operating system 
which records the system calls made by an application. 

Instrumented application : This method uses messages emitted directly by 
the application to be monitored. Common interfaces for an application to 
report events are the Unix system logger (syslog) or the Windows NT event 
logger. Other, more complex, interfaces include the X Open Distributed Au- 
diting Standard (XDAS) and Event Management Service (XEMS) EH . 




Interception 3rd Party Instrumentation Application Instrumentation 



Fig. 2. IDS Data Acquisition Methods 



Intrusion detection systems which monitor applications by interception are 
by far the most common and have the advantage that they are easily deployed — 
existing systems need not be modified or reconfigured, and since their monitoring 
is passive, these IDSs are unobtrusive. 
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Unfortunately intercepting IDSs also have a number of disadvantages: 

— Interactions between components may be stateful, and this state may be 
maintained for extended periods of time. For example, hosts communicating 
via TCP/IP have to allocate resources for each connection, while the UNIX 
system call interface uses file descriptors to encode state. An IDS needs 
to allocate duplicate resources to shadow this state — it has to remain 
synchronized with the components being monitored. 

— The interface between components may be underspecified, or implementa- 
tions may not honour the specifications. This means that the decoding com- 
ponent of the IDS may have to be significantly more complex than the inter- 
face of any individual application to cover all implementations and revisions. 

— An intercepting IDS operates under severe time constraints, having to keep 
up with the monitored application at all costs. Essentially the worst case 
performance of the IDS has to exceed the best case performance of the mon- 
itored applications for a given set of circumstances. This is a significant 
limitation: It requires that the IDS operate within hard time limits, even 
though the monitored application need not. For example, an overloaded ap- 
plication may be free to drop a message and wait for a retransmission, an 
overloaded intercepting IDS is unable to do so. 

— Communications channels between applications are ever more likely to be 
secured cryptographically. These measures are explicitly designed to prevent 
third parties from intercepting traffic — which is exactly how most intrusion 
detection systems operate. Currently encryption is only widely used in net- 
worked communications, but it appears likely that systems such as digital 
content managers, smart card resident applications or agents participating 
in electronic commerce will extend cryptographic protection to other sub- 
systems. 

The limitations of an intercepting IDS can be expressed slightly more for- 
mally: An application can be viewed (simplistically) as a function / taking as 
parameters the current application state St and some input i, and returning some 
output o and the next state St+i: 

= {ot,St+i) ( 1 ) 

Borrowing concepts from m, we can partition the set of states S into two 
nonoverlapping subsets, those states in which the application is in a safe state 
s € Ss, and those states which denote a compromise s € Sc- 

SsnSc = 9 (2) 

An intercepting intrusion detection system can be defined as a function d 
which will reconstruct the state of an application from the traffic available to it: 

d{e,pt,qt, mt) = (mt+i, nt) (3) 

Here e describes the application, p and q the observed application input and 
output, while m denotes the state of the IDS and n the shadowed or mirrored 
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state of the application. For an IDS to be effective, it needs to remain synchro- 
nized with the application it is protecting, n = s, as this enables it to decide if 
the application has entered a compromised state. 

Note that s, the state of the application itself is unavailable to the intercepting 
IDS and has to be inferred. 

For an arbitrary application / an intercepting IDS may become unreliable if: 

— The observed inputs and outputs are unreliable or incomplete: p ^ i and 
q^o. 

— The application state exceeds that of the IDS: |A^| < IS”!, allowing for state 
holding attacks against the IDS. 

— The application description available to the IDS is underspecified or inac- 

curate: Bit V Bot : d{e,it,Ot,mt) = imt+i,rit), f{it, St) = {ot,St+i) such that 
Bu ^ t . iuj Ou , '^u) — 5 ’^u) ^ f ^u) — . 

— The initial application state Sq is unknown to the IDS preventing it from 
initialising its own state toq by some setup function 6(e, sg) = wo- Crypto- 
graphically secured applications are an example of this case: sq contains a 
secret which is unavailable to the IDS. 

The above conditions offer enough possibilities to desynchronize most non- 
trivial monitoring systems. 

The risk of desynchronization attacks against intercepting NIDS are rea- 
sonably well understood. They have been described in ini, and tools such as 
fragrouter and whisker m make these capabilities available to the attacker 
population at large. 

4 Instrumentation 

Instrumenting applications or other components for the purpose of monitoring 
a system and detecting intruders has a higher initial cost, as it requires modi- 
fications to existing components. However, as it is more tightly coupled to the 
monitored entity, it is less likely to be desynchronized. Instrumentation as op- 
posed to interception is the technique favoured by host-based intrusion detection 
systems. 

The most common form of instrumentation used by host-based intrusion 
detection systems is the audit trail of the operating system which records the 
sequence of system calls made by the application. It belongs to the instrumented 
third party monitoring category, as the monitored entity is the application, but 
the information is collected by the operating system (refer back to Fig. |2I). US- 
TAT PH and ASAX PS| are examples of intrusion detection systems which 
process the host audit trail. 

The audit trail illustrates some of the features of instrumented third party 
monitoring: 

— The time constraints are less rigid than those imposed on an intercepting 
IDS. For example, an operating system writes audit records regardless of 
system load — generating more audit records will slow down the applica- 
tion, not result in dropped messages — as a matter of fact the Solaris BSM 
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audit module will even suspend execution when it is unable to write new 
records. Similarly an application level security proxy may drop packets un- 
der load, relying on the application to retransmit them. This contrasts with 
an intercepting system where even a single missed message may result in an 
intrusion attempt going undetected. 

— The state information maintained by the third party need not be duplicated 
by the IDS. For example, a Unix operating system needs to maintain the 
mapping from file descriptor to file and offset within file — this mapping 
need not be duplicated if made available to the IDSQ In other words, state 
information is at least partially available. 

While instrumenting third parties has its merits, we believe that instrument- 
ing applications directly has a number of additional benefits: 

— A direct instrumentation makes it possible to take advantage of the appli- 
cation designer’s knowledge to perform the task of feature selection. Feature 
selection is the identification of relevant events or criteria, often performed 
as a preprocessing step before submitting data to a machine learning sys- 
tem (see m for some of the issues involving feature selection and intrusion 
detection). Feature selection can reduce data volumes significantly and con- 
sequently improve system performance. Consider a system call trace — a 
write 0 call at one stage may have minimal security implications (e.g. print 
a debug message to a terminal), another write () might be critical (e.g. 
update /etc/passwd). Having the application designer indicate which are 
significant simplifies the task of the IDS. 

— End to end cryptographic protection may extend into the application, mean- 
ing that the read and write buffers visible to a third party in the form of a 
system call trace only contain cyphertext. 

— Optimized applications may precompute data or cache results, a third party 
might receive highly variable information, even though the underlying activ- 
ity has remained constant — such a situation may make it difficult to train 
an anomaly detector or specify a complete signature. 

— The converse of the previous point may also occur: Different activities may 
appear the same to a third party — consider a task such as reading a line 
from a file, computing its hash and sending the hash to a remote system. 
Leaving out the hashing step might not alter the audit trail recorded by the 
operating system. 

— Applications may provide their own protection subdomains and execution 
environments. Security violations internal to an application may not be vis- 
ible to a third party — for example attempts to escalate rights within a 
database server may not generate any distinctive system calls, while a macro 
virus attack might not generate any system calls at all. 

We believe that instrumenting applications directly for the purpose of de- 
tecting subversions has not yet been explored fully, and this is the motivation 
for introducing the IDS/A interface. 

^ The recommendation made by m suggests that individual audit records should be 
selfcontained. Recording the file name (as well as file descriptor) to which a write () 
is made would be in the spirit of that recommendation. 
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5 Intrusion Response 

One of the difficulties confronting the designers of intrusion detection systems is 
the matter of responding automatically to suspected intrusions. 

On the one hand it is desirable to have the IDS respond automatically to 
limit, isolate or even prevent an intrusion. On the other hand many alerts are 
false alarms and responding in error may have undesirable consequences. For 
example, it may provide an opportunity for an attacker to mount denial of 
service attacks. 

Unfortunately it appears that false positives are difficult to eliminate entirely 
from anomaly detection systems |2| . However, it should be possible to reduce the 
costs of erroneous responses: Current intrusion responses are quite coarse and 
crude — typically intercepting NIDS are limited to inserting firewall rules or 
resetting open network connections. 

We suggest using a direct interface between application and IDS to make re- 
sponses more fine-grained and less vulnerable to subversion — we aim to achieve 
this by merging the functionality of reference monitor and IDS, making it pos- 
sible for access control policies and availability requirements to modulate IDS 
responses. 

6 A Direct IDS to Application Interface 

We propose a direct interface between IDS and application. The interface is in- 
tended to provide an online IDS with direct access to the application (monitoring 
by direct instrumentation, see Fig. EJ. 

Like the interface of the conventional Unix syslog or XDAS 1231, our interface 
is visible to the application programmer as a set of library calls. The library 
functions are used by the application programmer to report security relevant 
events. 

However, unlike a logging interface which merely records past events, our 
interface is a bi-directional interface designed to let applications submit pending 
events or actions to the IDS for approval. The interface can thus be viewed as 
an additional, external, voluntary reference monitor available to applications. 

We believe that the bi-directional property has a number of significant ad- 
vantages: 

— As the application awaits a reply from the IDS, it is no longer feasible to 
overload the IDS in the hope of having it discard events still visible to the 
target. 

— It becomes possible to institute a fail-closed policy — when the IDS is un- 
available, requests made by the application are simply denied. 

— As pending, instead of past, activity is reported it becomes possible to pre- 
vent intrusions by simply disallowing unauthorized actions. This allows for 
highly specific responses to attempted intrusions which are difficult to bypass 
or subvert. 



44 



M. Welz and A. Hutchison 



Initially it may seem counterintuitive to make an IDS an active component 
visible to applications. In particular, concerns may be raised about the perfor- 
mance implications of such an approach. However, with the exception of hard 
real-time applications|3 we believe that the costs of including an IDS can be jus- 
tified: A “fair-weather” IDS which is too slow to keep up with worst case traffic 
is of limited use as an attacker may simply generate spurious traffic to overload 
and so blind the IDS. 

Real protection requires that every event be viewed by the IDS — integrating 
the IDS into the infrastructure (and slowing the rest of the system down to the 
speed of the IDS, if required) makes it possible to guarantee this. 

The direct coupling of IDS to application may actually have lower overall 
resource demands than a conventional intercepting IDS. A directly coupled IDS: 

— uses the state information reported by the application, doing away with the 
need to duplicate state 

— does not need to perform message decoding/decryption, as this is done by 
the application 

— has to filter out less extraneous information as it is only consulted by an 
application when necessary 

The reference monitor characteristics of the interface make intrusion preven- 
tion possible — a suspicious action is simply disallowed. This response is simple, 
yet highly specific and difficult to circumvent. Where the IDS is insufficiently 
competent to act as reference monitor, it may simply allow all requests, turning 
the interface into a synchronous logging subsystem. 

6.1 Event Reporting 

Our approach relies on the application to provide information to the IDS. We 
define three types of information which the application should provide: 

1. Credentials: The application needs to identify itself to the IDS in order 
to have the IDS distinguish between different applications and application 
domains. 

2. Domain specific information: This information and its semantics depend on 
the domain which in which the application operates — a database server 
would have a different vocabulary to a mailer. 

3. Domain independent information: This information remains unchanged 
across application domains. It provides a fallback in case a given IDS lacks 
the knowledge for a particular application domain. 

We believe that a separation between domain dependent and independent 
information is a reasonable approach to managing complexity. Designing a se- 
mantics which covers all conceivable applications would be an enormous task, 

^ Even if real-time response times are required, it may be possible to involve an IDS: 
A pending action can be submitted to the IDS — if no response is received within a 
fixed period of time, the action is denied (if a fail-closed policy is active) or allowed 
(in the case of a fail-open policy). 
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and if ever completed would inevitably result in poor fits, requiring application 
designers to shoehorn the events reported into an awkward scheme. Instead we 
have decided on a two tiered approach, leaving the domain dependent part en- 
tirely to the individual application^ and designing a simpler (yet still interesting) 
domain independent security rating. 

Requiring that an IDS have knowledge of the internals of an application is 
a reasonable demand as this is how current misuse detection systems operate 
— misuse detectors make use of deep domain knowledge to construct signatures 
which are triggered by known attacks. 

The domain independent security rating which we propose is an attempt to 
have applications describe the security implications of their actions to an IDS. We 
suggest that actions be rated according to their estimated impact on availability, 
confidentiality and integrity. The estimate consists of a severity and a confidence 
value. Additionally it may be possible to include information describing which 
assets are affected by such actions. 

For example, a request made by an ftp server to process a NQDP instruction 
sent by a client might be designated a low risk rating in all three categories, 
while a DELE request to remove a file might carry a significant risk to availability. 
Such assessments should be reasonably straightforward and a good number of 
application programmers should be able to rate the actions of their applications 
on such a scale. It may also be possible to involve the security designations or 
labels associated with the entities affected by such actions. For example, allowing 
the transfer of a Unix file not globally readable might carry a greater risk of 
breaching confidentially than one accessible to all local users. 

Such a security rating provided by those who design and implement trusted 
applications may be useful in a number of tasks: 

— Anomaly detection systems may be able to use the ratings to guide their 
feature selection or data reduction components. 

— Automated response policies can include availability costs, and base their 
decisions on the tradeoff between availability and integrity or confidentiality. 

— The ratings themselves may be useful to an IDS — for example an increase 
in the number of events with higher than usual threats to confidentiality 
might indicate that the system is under reconnaissance by an attacker. 

While the rating system has been kept simple deliberately in order to make 
it accessible to application programmers, it is sufficiently powerful to express the 
tradeoffs between availability on the one hand, and confidentiality and integrity 
on the other which underlie the field of computer security. The rating system 
makes it possible to specify this tradeoff for individual applications — some, like 
mail, are essential and need to be available despite large risks, others, such as 
anonymous ftp, can be suspended by the IDS at the first sign of intruder activity. 



^ We do provide a means whereby related applications can use a common event sub- 
space or scheme with agreed upon structure and semantics. 
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7 IDS/ A: Implementation 

We have built an experimental platform which implements some of the concepts 
set out in the previous section. While the implementation is still volatile and 
likely to be reworked, parts of it have been running on a number of workstations 
and servers in operational use for about a year. 

Architecturally our implementation resembles the conventional Unix system 
logger. Like syslog our system consists of a set of library functions linked to 
applications and a central daemon idsad which collects events from applications. 
Like syslogd, idsad communicates with applications via a Unix domain socket, 
and messages consist of a set of label value pairs similar those proposed by HD 
Unlike syslog, our interface is bi-directional, allowing idsad to act as reference 
monitor for applications. 




Fig. 3. Selected IDS/ A Components 



idsad, in its current version, is primarily a misuse detector — signatures 
are specified using a simple rule language resembling that of a stateful firewall. 
However, we do provide a plugin interface which can be used to load additional 
detection modules at runtime, including anomaly detectors. 

7.1 Performance Issues 

Interprocess communication between idsad and application imposes a perfor- 
mance penalty — we have attempted to reduce this impact by shifting the in- 
trusion detection components into the application context/process space when 
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appropriate. This approach bears some resemblance to the one used by m to 
manage distributed applications. 

The detection components running inside the application may either be used 
as a filter to select only interesting events to forward to idsad, or may be used 
to have the application perform its own autonomous intrusion detection, access 
control and logging — see Fig. 01 The modules performing these tasks in the 
application context are the same shared objects which are used by idsad. As all 
this activity occurs inside IDS/ A library calls, it is transparent to the application 
and an application may be instructed to switch from reporting to idsad to 
operating autonomously on the fly. 
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libidsa 



Thin library 
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idsa plugins 
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Library prefilter 



application 
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Fig. 4. Shifting Intruder Detection into the Application Context 



Using a simple, synchronous API implemented as a shared library also makes 
it possible to substitute alternative implementations without needing to mod- 
ify an already instrumented application. Such substitutions could be made to 
implement future extensions, for example it might be interesting to support dis- 
tributed detection and policy management across different hosts or architectures 
(scaling up) or implement a lightweight highly-speciflc library for an embedded 
appliance system (scaling down). 



8 Example Applications 

We have directly instrumented a number of applications to use idsad as reference 
monitor. Amongst others: 
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— Apache using a module mod_idsa to request permission to process HTTP 
requests. 

— Two experimental ftp servers which allow idsad to monitor and block indi- 
vidual ftp requests. 

— Applications performing access control such as login, xdm or xlock using a 
pluggable authentication module m which reports authentication requests 
to idsad for approval. 

In addition to the direct instrumentation of applications, we have also in- 
strumented a number of wrappers to perform third party monitoring and even 
interception. Examples of these include: 

— A TCP wrapper m replacement to take access control decisions for services 
started by the inetd superserver. Services which can be controlled using 
TCP wrappers include finger and telnet. 

— A suite of application level proxies C2I similar to the firewall toolkit of 

TIS [ini. 

— A preloaded library to intercept exec system calls to invoke new programs. 

These are examples to show that the IDS/ A interface can not only be used 
for direct application instrumentation but also third party instrumentation and 
even interception. 

Lastly we have also provided a number of applications which only report 
events, using idsad merely as an extended logger instead of as a reference moni- 
tor. As an example we have provided a syslog shim which maps syslog messages 
to IDS/ A events and reports them to idsad. 

Further applications are in various stages of development — of particular 
interest are those applications which cross protection domains internal to an 
organization (e.g. groupware) as this may make it possible to counter internal 
threats, often the most damaging. 

9 Example Signatures 

An example illustrates how IDS/ A can be used to restrict the functionality of 
an application with a known vulnerability — a typical application for a misuse 
detection system: Some versions of ftpd implement the SITE command inse- 
curely. At some installations ftp might be an essential service and it may not be 
possible to update ftpd immediately (e.g. because a fix is not yet available). 

If the ftp server has been instrumented using the IDS/ A API, then the fol- 
lowing idsad rule could be used to reject SITE commands instead of having to 
disable ftp completely^ 

service ftpd & scheme ftp & uid ftp & cmd=string SITE: 
deny; log file /var/Iog/idsa/ftpd-site-attempts 



^ Some of the mechanisms proposed in j20| to initiate the orderly termination of flawed 
programs could conceivably be modified to automate this contraction of functional- 
ity. 
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The rule applies to applications which register themselves as ftpd using the 
scheme ftp, running under the Unix user id ftp. 

It is also possible to specify such access rules/signatures at a higher level: 

service ftpd & scheme ftp & uid ftp & irisk > 0.4 
& (! ipsrc 192.168.1.1/24 I "/time wday Sat, Sun): 
deny; log file /var/log/idsa/ftpd-risky-deny 

This rule denies risky ftp operations to users outside the local network or 
those connecting on weekends. If the designer of the ftp daemon has rated the 
SITE command as having a risk to system integrity (irisk) of over 0.4 (relative 
to other ftp commands) then this rule disables the command under a number of 
threatening circumstances. 

Note how the author of access rules is able to select between applying his own 
domain knowledge (see previous rule) or taking advantage of the knowledge of 
the application designer without needing to understand the application internals. 

Our system provides state variables to retain information across rules and 
events. These can be used to initiate more complex reactions to intrusions and 
intrusion attempts. For example, a state variable could be used to retain the 
IP address of an attacker probing the ftp daemon. The state information could 
then be used to block access to other services, such as using our TCP wrapper 
replacement to block access to finger or telnet or having mod_idsa block HTTP 
access. Even more sophisticated tests might involve machine learning systems to 
discover anomalous usage patters. However, the above rules are already sufficient 
to block an intrusion and do so without manual intervention and minimal risk 
of subversion. 



10 Results 

We have created a number of signatures which can transiently block out the 
more obtrusive bulk vulnerability scanners: For example, mod_idsa can be used 
to block CGI vulnerability scanners, while the application level proxies or TCP 
wrapper replacement can be used to block banner grabbing scanners. Although 
the block is transient, the response codes sent to the scanner indicate a perma- 
nent failure discouraging further probing. 

Apart from ourselves using tools such as whisker m to probe an installation, 
we have been running idsad on a server as part of its normal operation, idsad 
has blocked several real-world banner grabbing scans, as well as a number of 
rogue web crawlers which did not honour robots.txt or even tried to access 
forbidden areas deliberately. 

In order to develop further confidence in IDS/ A as a reasonable misuse de- 
tection system, more tests are being conducted and additional rule-bases con- 
structed. 

The anomaly detection capabilities of idsad are still under development, and 
no results can be reported on this aspect. 

It is difficult to provide a general estimate of the performance costs of using 
our system to instrument an application, as this depends heavily on how and 
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where the application designer inserts IDS/A calls. However, we have provided 
a brief overview of the performance impact for mod_idsa, the apache module. 
Tests were performed using the httperf tool with 1000 GET requests for the 
same entity. We ran three tests: 

1. A request for a directory listing made to a web server running on the local 
host. Directory listings are expensive as they generate multiple IDS/A calls. 

2. A request for a small file for a server on the local host since a request for a 
large file would have masked the costs of IDS/ A calls. 

3. A request for a small file on a remote server, where the remote server is 
situated on the same ethernet. 





No mod_idsa 


Test in idsad 


Test in httpd 


1. local directory listing 


14.69 


26.80 (82.4%) 


17.42 (19.0%) 


2. file on local server 


5.22 


6.28 (20.0%) 


5.86 (12.0%) 


3. file on remote server 


15.60 


16.51 (5.9%) 


15.95 (2.3%) 



Fig. 5. Performance impact of instrnmenting apache. Units are in seconds to process 
1000 requests. Percentages indicate cost of instrumentation 



It can be seen that for an expensive operation such as a directory listing 
the cost of contacting idsad can be significant, with an overall slowdown of 
82%. When the test is shifted into the application context (see Fig. EJ this 
drops to 19%. For realistic scenarios — a request for a short file from a remote 
server, IDS/ A instrumentation costs drop to a level which we consider acceptable 
(2.3%). 

11 Discussion 

We acknowledge that our approach has limitations, it requires that an applica- 
tion be modified to provide reliable information, and that some attacks might be 
able to compromise a trusted application before it is able to report the attack. 
However, conventional intrusion detection systems are also fallible — the entire 
field of intrusion detection is a best effort. 

Our approach can be seen as another layer of an in depth defence, with differ- 
ent modes of failure to those encountered in conventional intercepting systems. 

By making a generic reference monitor available to application programmers 
it becomes possible to provide a unified system for securing applications — 
already some trusted applications such as web browsers allow their users to 
select a certain level of security. We believe that our API makes this easier: An 
application programmer need not create his own reference monitor, but can use 
our system. Applications are becoming evermore complex and feature rich, and 
it seems unlikely that this trend will be reversed — we provide an API which at 
least makes it possible to disable functionality selectively. 
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In many ways our system can be viewed as offering a second opinion to 
an application — like the medical practitioner who consults another party for 
an important decision, so our system can be used as another reference monitor 
which can be consulted when making a decision which has an impact on security. 



12 Related Work 

Our interface can be thought of as an extension of the uni-directional applica- 
tion logging interfaces such as the conventional Unix syslog or the NT event log. 
More complex logging subsystems include the X/OPEN Distributed Auditing 
Standard (XDAS) which can be described as logging middleware. An ex- 
ample of an IDS using application specific audit information is DEMIDS a 
database misuse detection system. 

Some system management architectures provide for a bi-directional instru- 
mentation of applications, e.g. SNMP n or the X/OPEN XEMS PI- However, 
these interfaces have a different focus, dealing with such tasks as starting and 
stopping services or exporting service definitions. 

Interfaces which have the exchange of security information as their primary 
focus include the one designed by the IETF IDWG [3| or the communications 
channels of distributed intrusion detection systems such as AAFID Pj , although 
the focus of those interfaces is on coupling different IDS components, as opposed 
to our interface intended to couple an IDS to applications. 

Recent examples of directly instrumented systems include the embedded sen- 
sor project (ESP) jI2| which has modified a kernel to log network misuse. At the 
application level, Kava m is an example of a system to enforce access control 
policies for mobile code. 

The concept of having an application consult a third party for an additional 
security decision can be related to aspects of reliable programming, in particular 
N version programming where several instances perform the same computation. 
In our case the access control decisions are verified by a second, external reference 
monitor. 

Systems such as JANUS P, Medusa DS9 |27] and LOMAC |S] also attempt 
to influence applications actively (as opposed to mere monitoring). However, 
whereas these systems influence applications via a third party (typically by 
rewriting operating system calls), our interface attempts to do so directly. 

13 Conclusion 

We have presented an external, nonspecific, voluntary reference monitor acces- 
sible through a simple API. Requests are described to the reference monitor in 
two ways: As a domain independent set of risk assessments and as a domain 
specific description. 

We believe that such a reference monitor can be used as an adjunct or al- 
ternative to conventional intercepting intrusion detection systems. Conventional 
intercepting IDSs are vulnerable to a number of desynchronization attacks and 
only have limited response and prevention capabilities. 
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By encoding misuse signatures as negative access rights, our reference mon- 
itor can be used to prevent attempted intrusions with a reasonable degree of 
safety, and with a limited potential for desynchronization. The domain indepen- 
dent risk ratings can be used to constrain the effects of a response as well as a 
guide to anomaly detection systems. 

While our approach has the disadvantage of requiring the co-operation of 
application programmers and is dependent on accurate application logging, the 
failure modes of our approach are sufficiently different from those of conventional 
intrusion detection systems to make it an interesting component of an in-depth 
defence. 

14 Source 

The IDS/A homepage is http://jade.cs.uct.ac.za/idsa/ and parts of the 
implementation are available for download. 
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Abstract. With the growing deployment of host and network intrusion 
detection systems, managing reports from these systems becomes 
critically important. We present a probabilistic approach to alert 
correlation, extending ideas from multisensor data fusion. Features 
used for alert correlation are based on alert content that anticipates 
evolving IETF standards. The probabilistic approach provides a nnified 
mathematical framework for correlating alerts that match closely but 
not perfectly, where the minimum degree of match required to fuse 
alerts is controlled by a single configurable parameter. Only features 
in common are considered in the fusion algorithm. For each feature 
we define an appropriate similarity function. The overall similarity 
is weighted by a specifiable expectation of similarity. In addition, a 
minimum similarity may be specified for some or all features. Features 
in this set must match at least as well as the minimum similarity 
specification in order to combine alerts, regardless of the goodness of 
match on the feature set as a whole. Our approach correlates attacks 
over time, correlates reports from heterogeneous sensors, and correlates 
multiple attack steps. 

Keywords: Network security, sensor correlation, alert management, 
adaptive systems. 



1 Introduction 

In response to attacks and potential attacks against enterprise networks, admin- 
istrators are increasingly deploying intrusion detection systems (IDSs). These 
systems monitor hosts, networks, critical files, and so forth, using a variety of 
signature and probabilistic techniques P2|. The use of such systems has given 
rise to another difficulty, namely, correlating a potentially large number of alerts 
from heterogeneous sensors. To the degree that this has been addressed in cur- 
rent systems, heuristic techniques have been used. In this paper, we describe a 
probabilistic approach to this critical problem. 

The intrusion detection community is actively developing standards for the 
content of alert messages Systems adhering to these evolving standards for- 
ward attack descriptions and supporting diagnostic data to an alert management 
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and N66001-00-C-8058. The views herein are those of the author(s) and do not 
necessarily reflect the views of the supporting agency. 
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interface (AMI), which may be remotely located and consolidating the reports 
of numerous sensors. In anticipation of these standards, we are evolving systems 
for alert correlation and ranking. 

In 0 we introduced sensor coupling and an initial approach to probabilis- 
tic sensor correlation. At the time, we demonstrated the utility of the coupled 
sensors approach for false alarm reduction and improved detection performance. 
We also introduced a correlation approach based on feature-specific similarity 
functions. The correlation example cited at that time consisted of a single sensor 
examining a probe that was distributed in time. Since then, we have introduced 
some important innovations: 

— Capability to comprehend heterogeneous sensors. 

— Introduction of the probabilistic minimum match criterion, which prevents 
spurious matches on less important features from causing the system to cor- 
relate alerts. By specifying minimum match of unity, this capability causes 
the system to function as a rule-based correlation system. Explicitly tol- 
erating slightly imperfect matches provides an important generalization of 
rule-based correlation methods. 

— Hierarchy of sensor correlation: thread, incident, and correlated reports from 
multistep attack scenarios. 

We have also gained considerable experimental experience in both live and 
simulated environments. 

The remainder of this paper is organized as follows. We introduce our ap- 
proach to alert fusion, using our defined alert template to report alerts from 
EMERALD and third-party sensors. We introduce notions of feature overlap, 
similarity, expectation of similarity, and minimum similarity. We show how these 
are used to achieve a hierarchy of alert correlation defined as inferred thread 
(within sensor), security incident (between sensor) and correlated attack report 
(between sensor and attack step). We then present preliminary results from the 
alerts generated by various EMERALD and third-party monitors m 

2 Sensor Correlation and Alert Fusion 

In 0, we introduced probabilistic methods for sensor correlation. Specifically, 
we considered two closely coupled sensors, a TCP misuse monitor and an asset 
availability monitor. Both are based on Bayes inference 0, and the former sen- 
sor is aware of the state of the latter. Sensor coupling in this fashion is easily 
expressed in Bayes formalisms; specifically, the coupling is achieved by dynami- 
cally modifying priors in the TCP session monitor. The approach demonstrated 
two important capabilities: 

— Failed accesses to services that appear to be invalid are viewed with greater 
suspicion than other failed accesses. This greatly increases sensitivity against 
certain stealth probe attacks. 
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— Certain types of failed access to services that appear “down” are tolerated, 
so that when a service fails (for malicious or accidental reasons) we do not 
generate a large number of false alarms. 

Having demonstrated the utility of sensor fusion for improved sensitivity and 
false alarm reduction, we have further explored the general problem of sensor 
correlation. In particular, we examine the situation of multiple heterogeneous 
sensors on diverse platforms, considering realistic problems of late reports and 
clock drift. 

Our correlation algorithm considers features as reported in a standard alert 
template. For each matchable feature, we have defined an appropriate similarity 
function that returns a value between 0 and 1. New alerts are compared to a list of 
existing meta alerts. The overall similarity is the weighted average of the feature 
similarities, with expectation of similarity as the normalizing weights. If the 
minimum match criterion fails for any feature, the match is rejected regardless 
of the overall similarity. The new alert is correlated with the most similar meta 
alert, assuming the similarity is above a specified minimum match threshold. 
Otherwise, the new alert starts a new meta alert thread. 



2.1 Meta Alerts and the Alert Template 

We have defined an enhanced alert template that enriches standards such as 
lETF/IDWG |5| with respect to content while avoiding issues of language 
specifics. Our template includes the concept of alert thread, which is present 
in all EMERALD monitors and alert management components. Alert reports 
are part of the same thread if they are from the same sensor and refer to the 
same attack, possibly separated in time. Where provided, such as is the case 
with EMERALD monitors, the thread mechanism causes new reports for an ex- 
isting thread to be treated as updates, dramatically reducing clutter on a display 
interface that comprehends threads. For this reason, we identified the capability 
to reliably infer thread when the sensor does not provide one as a very desirable 
capability of alert correlation. 

We include an “anomaly” field in addition to the “confidence” field used in 
the evolving IETF standard. We also include arrays to describe in greater detail 
the target (s) of an attack (for example, the specific ports scanned). Finally, we 
include fields describing the sensor type and placement, enabling us to identify 
each unique instantiation of any sensor in the monitored domain. 

This template is presently used by a diversity of sensors employing both 
signature and probabilistic techniques. This includes sensors that we have de- 
veloped under the EMERALD program, as well as prototype wrappers for ISS 
RealSecure and Checkpoint Firewall-1. Our early experiments indicate that di- 
verse sensors will be able to fill this template with content that will be more 
useful to correlation engines than is currently available. 
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2.2 Feature Similarity 

Our probabilistic alert fusion approach considers feature overlap, feature simi- 
larity, minimum similarity, and expectation of similarity. We maintain a list of 
“meta alerts” that are possibly composed of several alerts, potentially from het- 
erogeneous sensors. For two alerts (typically a new alert and a meta alert), we 
begin by identifying features they have in common (feature overlap). Such fea- 
tures include the source of the attack, the target (hosts and ports), the class of 
the attack, and time information. With each feature, we have a similarity func- 
tion that returns a number between 0 and 1, with 1 corresponding to a perfect 
match. Similarity is a feature-specific function that considers such issues as 

— How well do two lists overlap (for example, list of targeted ports)? 

— Is one observed value contained in the other (for example, is the target port 
of a denial-of-service (DOS) attack one of the ports that was the target of a 
recent probe)? 

— If two source addresses are different, are they likely to be from the same 
subnet? 

For attack class similarity, we maintain a matrix of similarity between attack 
classes, with values of unity along the diagonal and off-diagonal values that 
heuristically express similarity between the corresponding attack classes. We 
prefer to consider attack classes rather than attack signatures, which are much 
more specific and numerous but may be erroneously or incompletely reported. 
For example, in our demonstration environment, we run a variant of mscan that 
probes certain sensitive ports, that is, it is of the attack class “portsweep” . Our 
host sensors have a specific signature for this attack and call it “mscan”. The 
Bayes sensor trades specificity for generalization capability and has no “mscan” 
model, but successfully detects this attack as a “portsweep”. These reports are 
considered similar {S = 1) with respect to attack class. 

Not all sensors produce all possible identifying features. For example, a host 
sensor provides process ID, while a network sensor does not. Features not com- 
mon to both alerts are not considered for the overall similarity match. 

The meta alert itself supports the threading concept, so we can visualize 
composing meta alerts from meta alerts. 



2.3 Situation-Specific Similarity Expectation 

An important innovation we introduce is expectation of similarity. As with sim- 
ilarity, this is also between 0 and 1, and expresses our prior expectations that 
the feature should match if the two alerts are related, considering the specifics 
of each. For example, two probes from the same target might scan the same 
set of ports on different parts of our subnet (so expectation of matching target 
IP address is low). Also, some attacks such as SYN FLOOD spoof the source 
address, so we would allow a match with an earlier probe of the same target 
even if the source does not match (expectation of match for source IP is low) . 




58 



A. Valdes and K. Skinner 



We now give some examples of how expectation of similarity depends on the 
situation, that is, the features in the meta alert and the new alert. 

If an alert from a sensor has a thread identifier that matches the list of 
sensor/thread identifiers for some meta alert, the alert is considered a match and 
fusion is done immediately. In other words, the individual sensor’s determination 
that an alert is an update of or otherwise related to one of its own alerts overrides 
other considerations of alert similarity. 

If the meta alert has received reports from host sensors on different hosts, 
we do not expect the target host feature to match. If at least one report from 
a network sensor has contributed to the meta alert and a host sensor alert is 
received, the expectation of similarity is that the target address of the latter is 
contained in the target list of the former. 

In determining whether an exploit can be plausibly considered the next stage 
of an attack for which a probe was observed, we expect the target of the exploit 
(the features host and port) to be contained in the target host and port list of 
the meta alert. 

Some sensors, particularly those that maintain a degree of state, report start 
and end times for an attack, while others can only timestamp a given alert. 
The former deal with time intervals, while the latter do not. Similarity in time 
comprehends overlap of the time intervals in the alerts considered for correlation, 
as well as the notion of precedence. We do not penalize time similarity too far 
from unity if the time difference is plausibly due to clock drift. 

Deciding whether the attacker is similar is somewhat more involved. In the 
case of an exact match of originating IP address, similarity is perfect. We as- 
sign high similarity if the subnet appears to match. In this way, a meta alert 
may potentially contain a list of attacker addresses. At this point, we consider 
similarity based on containment. In addition, if an attacker compromises a host 
within our network (as inferred by a successful outcome for an attack of the 
root compromise class), that host is added to the list of attacker hosts for the 
meta alert in question. Finally, for attack classes where the attacker’s address 
is likely to be spoofed (for example, the Neptune attack), similarity expectation 
with respect to attacker address is assigned a low value. 



2.4 Minimum Similarity 

Our correlation component implements not just expectation of similarity (which 
effectively acts as a weight vector on the features used for similarity matching) 
but also enforces situation-specific minimum similarity. Certain features can be 
required to match exactly (minimum similarity for these is unity) or approxi- 
mately (minimum similarity is less than unity, but strictly positive) for an alert 
to be considered as a candidate for fusion with another. Minimum expectation 
thus expresses necessary but not sufficient conditions for correlation. 

The overall similarity between two alerts is zero if any overlapping feature 
matches at a value less than the minimum similarity for the feature (features 
for which no minimum similarity is specified are treated as having a minimum 
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similarity of 0). Otherwise, overall similarity is the weighted average of the simi- 
larities of the overlapping features, using the respective expectations of similarity 
as weights. 

By appropriate settings of similarity expectation and minimum similarity, 
the correlation component achieves the following hierarchy of correlation. The 
system is composable in that we can deploy multiple instances to obtain cor- 
relation at different stages in the hierarchy. For example, we can infer threads 
(within sensor correlation) and then correlate threaded alerts from heterogeneous 
sensors into security incidents. 

Synthetic Threads: For sensors that do not employ the thread concept, the 
correlation synthesizes threads by enforcing high minimum expectation similarity 
on the sensor itself (the thread must come from a single sensor) and the attack 
class, as well as source and target (IP and ports). We have wrapped the alert 
messages from a leading commercial sensor and observed that this facility reliably 
reconstructs threads. 

In particular, by placing an aggregator component topologically close to an 
IDS, the pair is made robust against attacks that cause the IDS itself to flood, 
as described in a recent NIPC advisory 0. 

Security Incidents: By suppressing minimum expectation of similarity on 
the sensor identifier, and relaxing expectation of similarity for this feature, we 
can fuse reports of the same incident from several heterogeneous sensors into a 
single incident report. In this case, we enforce a moderately high expectation 
of similarity on the attack class. This is not unity because different sensors 
may report a different attack class for the same attack. We construct a table of 
distances between attack classes that expresses which ones are acceptably close. 
For security incident correlation, we enforce minimum expectations on the source 
and target of the attack. Using this technique, we have been able to fuse alert 
reports from commercial and EMERALD sensors into security incident reports. 

Correlated Attack Reports: By relaxing the minimum expectation of 
similarity on the attack class, we are able to reconstruct various steps in a 
multistage attack. Each stage in an attack may itself be a correlated security 
incident as described above. In this fashion, it is possible to recognize a staged 
attack composed of, for example, a probe followed by an exploit to gain access 
to an internal machine, and then using that machine to launch an attack against 
a more critical asset. 



2.5 Feature Fusion 

When the system decides to fuse two alerts, based on aggregate similarity across 
common features, the fused feature set is a superset of the features of the two 
alerts. Feature values in fused alerts are typically lists, so alert fusion involves 
list merging. For example, suppose a probe of certain ports on some range of the 
protected network matches in terms of the port list with an existing probe that 
originated from the same attacker subnet, but the target hosts in the prior alert 
were to a different range of our network. The attacker address list has the new 
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attacker address appended, and the lists of target hosts are merged. The port 
list matches and is thus unchanged. 

Two important features are the sensor and thread identifiers of all the com- 
ponent alerts, so that the operator is always able to examine in detail the alerts 
that contribute to the meta alert report. 

One additional feature is the priority of the meta alert, supported by our 
template and provided by EMERALD sensors. We are developing a component 
that estimates criticality based on the assets affected, the type of attack, the 
likelihood of attack success, and an administrative preference. The aggregator 
maintains the high water mark for this field. We are investigating approaches 
whereby the contributing threads are permitted to update their priority down- 
ward, computing meta alert priority as the maximum across thread priorities 
at any given time. This approach would permit downward revision of the meta 
alert priority. 

The features presently considered in the probabilistic correlator component 
include sensor identification (identifier, location, name), alert thread, incident 
class, source and target IP lists, target TCP/UDP port lists, source user id, 
target user id, and time. Computations are only over features that overlap in 
the alert to be merged and the candidate meta alert into which it is to be merged. 
Incident signature is used as well, but with a low expectation of similarity as 
these vary widely across heterogeneous sensors. 

If present, a thread identifier from the reporting sensor overrides other match 
criteria. A new alert that matches the sensor and thread of an existing meta alert 
is considered an update of the earlier alert. 

The correlator first tries to infer a thread by looking for an exact match 
in sensor identification and incident class and signature. Note that alerts that 
are inferred to be from the same thread may be separated in time. The system 
attempts to infer threads even in incident and scenario operational modes. 

Next the system checks that all overlapping features match at least at their 
minimum similarity value. Setting minimum expectation for some features to 
unity (not normally recommended) causes the system to behave like a heuristic 
system that requires exact matches on these features. Given that this criterion 
passes, we compute the overall similarity between the two alerts as follows: 



j:e,sim{x„y,) 

SIM{X,Y) = ^ 

j 

X = Candidate meta alert for matching 
Y = New alert 

j = Index over the alert features 
Ej = Expectation of similarity for feature j 
Xj, Yj = Values for feature j in alerts X and Y, 
respectively (may be list valued) 
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Incident class similarity is based on a notion of proximity, which at present is 
the result of our judgement. The proximity of class A to B reflects how reasonably 
an attack currently of incident class A may progress to class B. Note that this 
is not symmetric; we more strongly expect an exploit to follow a probe than the 
other way around. The incident classes are from the EMERALD 602 message 
format. Note that some “default” classes such as “invalid” and “action logged” 
are reasonably proximal to most other classes. This is because the IETF standard 
does not require a common ontology, and reports from heterogeneous sensors for 
the same incident may not reliably represent this field. As such, we do not want 
to reject potential matches based on this field alone. 

For operational modes other than thread level aggregation, we do not rec- 
ommend a high minimum similarity value for this field. 
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For two alerts that are extremely close in time, it is possible that the alerts 
may not be in time order. In this case, incident class similarity is the greater 
of SIM{X,Y) and SIM{Y,X). Mathematically, the similarity computation for 
incident class can comprehend a discrete call (the alert is from one of the above 
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classes) or a call that is a probability distribution over the above classes (as 
might result from a meta alert in which the contributing sensors do not agree 
on the class). 

Most other features are potentially list-valued. For lists, the notion of simi- 
larity generally expresses the fraction of the smaller list that is contained in the 
larger. For source IP addresses, similarity also attempts to express the notion 
that the addresses in question may come from the same subnet. 

Time similarity is a step function that drops to 0.5 after one hour. A close 
match in time is expected only when the system operates in “incident” mode. 
Thread and scenario aggregation may be over time intervals of days. 

3 Results 

3.1 Live Data 

The following is an example of alert correlation over time, in this case correlating 
alerts that are components of a stealthy port sweep. The following is an example 
of one of the contributing alerts. In the interest of space, we do not include all 
the content that is in the alert and meta alert templates, but limit ourselves to 
the fields needed to illustrate the result. 

Thread ID 69156 Class= portsweep BEL(class)= 0.994 BEL(attack)= 
1.000 

2001-06-15 17:34:35 from xx.yyy. 148.33 ports 1064 to 1066 

duration= 0.000 

dest IP aaa.bbb.30. 117 

3 dest ports: 12345{2> 27374{3> 139 

This is a probe for 3 vulnerable ports on a single IP address in the protected 
network, and is detected by the system described in 0. The above is just a 
single step in a probe that apparently transpired over several days, and resulted 
in the following correlated meta alert. 

Meta Alert Thread 248 

Source IPs source_IParray : xx.yyy . 148.33 xx . yyy . 148 . 47 

Target IPs target_IParray : aaa.bbb.30. 117 aaa.bbb.6.232 
aaa.bbb.8.31 aaa.bbb. 1 . 166 aaa.bbb.7. 118 aaa . bbb . 28 . 83 
aaa.bbb.19.121 aaa. bbb. 21. 130 aaa.bbb . 6 . 194 aaa.bbb. 1 . 114 
aaa . bbb . 16 . 150 

From 2001-06-15 17:34:35 to 2001-06-21 09:19:57 
correlated_alert_priority -1 

Ports target_TCP_portarray : 12345{4} 27374{4} 139{3} 
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Number of threads : 10 

Threads: 69156 71090 76696 84793 86412 87214 119525 
124933 125331 126201 
Fused: P0RT_SCAN 

We note that we have correlated events from two source addresses that were 
judged to be sufficiently similar. The attack is quite stealthy, consisting of a small 
number of attempted connections to single target hosts over a period of days. The 
list of thread identifiers permits the administrator to examine any of the stages 
in the attack. In this case, each attack stage is considered a portsweep; if the 
stages consisted of different attack classes, these would be listed under “Attack 
steps”. Over the three week time period containing this attack, the IDS sensor 
processed over 200,000 sessions and generated 4439 alerts. The probabilistic 
correlation system produced 604 meta alerts. 

3.2 Experimentation Environment 

The experimentation environment simulates an electronic commerce site, and 
provides Web and mail services over the Internet. The protected network is be- 
hind a firewall, and is instrumented with several host, network, and protocol 
monitors. Two machines are visible through the firewall, and two auxiliary ma- 
chines are used for network monitors and alert management. The firewall blocks 
all services other than Web, FTP, and mail. We have simulated traffic that 
appears to come from a number of sources, and an attacker who executes cer- 
tain well-known attacks. The background traffic includes legitimate anonymous 
and nonanonymous FTP use; the latter triggers false alarms in some signature 
sensors. There are also low-priority nuisance attacks, as well as low-level failed 
accesses to blocked ports, which trigger firewall log messages. 

The attack begins with an MSCAN probe to the two machines visible through 
the firewall. EMERALD eBayes and eXpert-Net sensors the two machines detect 
this and set the attack code for mscan in their alert report. The Bayes network 
sensor detects the attack as of the class “portsweep” . The target port lists for 
these alerts match, as does the attacker address. Similarity with respect to the 
target address depends on the order in which the alerts arrive (the order at which 
the alerts arrive is not deterministic as the sensors are distributed). Until the 
network sensor’s alert is received, we do not expect target addresses to match for 
distinct sensors, since a host sensor can typically report only its own address as a 
target. We expect the network sensor’s target list to contain the targets seen by 
host sensors (tolerating imperfect matches due to arrival order), and we expect 
the target address of subsequent host alerts to be contained in the meta alert’s 
target host list. Therefore, regardless of arrival order, these alerts are acceptably 
similar with respect to target host. 

The attacker next uses a CGI exploit to obtain the password file from the 
Web server. This exploit is detected by the host sensor. The next stage of the 
attack is a buffer overflow to gain access on the host providing mail service, 
detected by an EMERALD host sensor as well as by ISS. 
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Although telnet through the firewall is blocked, the attacker may telnet (using 
a password obtained from the earlier exploit) from the compromised internal host 
to the critical host, and he now does so. On that host, he uses another overflow 
attack to obtain root access. He is now free to change Web content. 

Figure 1 shows the EMERALD alert console for this scenario, containing 
alert reports for the above attack steps as well as alerts due to false alarms and 
nuisance attacks. It is not very informative, except to show that more than 1000 
alerts are received for this scenario, which lasts approximately 15 minutes, and 
the critical attack is effectively buried. 
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Fig. 1. Raw Sensor Alerts for the Simulated Attack Scenario 



The majority of the alerts are from nonanonymous FTP write operations, 
which are allowed but trigger alerts from a commercial sensor. 

Figure 2 shows the result of inferring synthetic threads for sensors that do not 
support the threading concept. For alert thread inference, we set the minimum 
match for sensor identifier fields to unity, and require a high match for attacker 
and target parameters as well; we do not require a minimum similarity in the 
time field to allow inference of threads that occur slowly over time. Most of the 
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alerts are threaded into sessions according to originating IP address, and the 
total number of alerts reported is reduced to about sixty. We have highlighted 
an alert, which is one of the nuisance TCP sweep attacks in the background 
traffic. 
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Fig. 2. Alert Fusion via Synthetic Thread Inference 



For attack incident matching, we must look across sensors to determine if 
several alerts refer to the same security incident. We suppress minimum similarity 
for sensors, set a moderately high similarity for attacker and target identifiers, 
and set a moderate minimum for time (to allow for clock drift and sensor response 
time differences). We also require a match in attack class, making allowances for 
sensors that report different attack classes for a given attack sequence. Figure 3 
shows the result of incident matching for the attack scenario. Some of the critical 
steps in the attack reported by several sensors now result in a single alert. For 
example, the highlighted buffer overflow attack is reported by an EMERALD 
sensor as well as by ISS. These are fused into a single correlated incident report. 
The two mscan reports from EMERALD host sensors and the portscan report 
from the EMERALD Bayes TCP sensor are also fused into a single incident. 
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Fig. 3. Security Incidents 



The final step in correlation is an attempt to reconstruct the attack scenario. 
We now relax attack class similarity to consider what attack steps might fol- 
low the present step. For example, it is reasonable to follow a probe with an 
exploit to a target “contained” in the probe. Also, if the meta alert includes a 
step indicating a likely root compromise, the host in question is added to the 
attacker’s assets (that is, it is both a victim and now a potential attacker as 
well). In Figure 4, the correlated attack report correctly lists as attacker assets 
his originating host, an internal host compromised at an intermediate step, and 
the spoofed address of the SYN flood stage. In this fashion, we have successfully 
combined both the external and internal threads of the attack scenario. 

It is worth pointing out that the EMERALD sensors in this experiment 
provide response directives which, if followed, would stop the attack in progress. 

4 Summary 

We have adapted and extended notions from the field of multisensor data fusion 
for alert correlation. The extensions are principally in the area of generalizing 
feature similarity functions to comprehend observables in the intrusion detection 
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Fig. 4. Correlated Attack Scenario 



domain. The approach has the ability to fuse alerts for which the match is good 
but not perfect. The method considers appropriate fields in alert reports as 
features for a multivariate matching algorithm. Only features that overlap are 
considered for the overall similarity calculation. For each matchable feature, 
we have defined an appropriate similarity function with range 0 (mismatch) 
to 1 (perfect match). Depending on the situation, we incorporate expectation 
of match values (which are used to compute a weighted average of similarity 
over the overlapping features), as well as a minimum match specification that 
unconditionally rejects a match if any feature fails to match at the minimum 
specified value. For each new alert, we compute similarity to existing meta alerts, 
and merge the new alert with the best matching meta alert, as long as the match 
passes a threshold value. We realize a reduction of one-half to two-thirds in alert 
volume in a live environment, and approach a fiftyfold reduction in alert volume 
in a simulated attack scenario. 
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Abstract. Intrusion detection relies on the information provided by 
a number of sensors deployed throughout the monitored network 
infrastructure. Sensors provide information at different abstraction 
levels and with different semantics. In addition, sensors range from 
lightweight probes and simple log parsers to complex software artifacts 
that perform sophisticated analysis. Managing a configuration of 
heterogeneous sensors can be a very time-consuming task. Management 
tasks include planning, deployment, initial configuration, and run-time 
modifications. This paper describes a new approach that leverages oft 
the STAT model to support a highly configurable sensing infrastructure. 
The approach relies on a common sensor model, an explicit represen- 
tation of sensor component characteristics and dependencies, and a 
shared communication and control infrastructure. The model allows an 
Intrusion Detection Administrator to express high-level configuration 
requirements that are mapped automatically to a detailed deployment 
and/or reconfiguration plan. This approach supports automation of 
the administrator tasks and better assurance of the effectiveness and 
consistency of the deployed sensing infrastructure. 

Keywords: Security, Software Engineering, Intrusion Detection, STAT. 



1 Introduction 



Any monitoring and surveillance functionality builds on the analysis performed 
by surveillance sensors. The intrusion detection community has developed a 
number of different systems that perform intrusion detection in particular do- 
mains (e.g., hosts or networks) and in specific environments (e.g., Windows NT 
or Solaris). 

These tools suffer from two main limitations: they are developed ad hoc for 
certain types of domains and/or environments, and they are difficult to configure, 
extend, and control remotely. In the specific case of signature-based intrusion 
detection systems j I WZW4\ the sensors are equipped with a number of signatures 
that are matched against a stream of incoming events. Most systems (e.g., P) 
are initialized with a set of signatures at startup time. Updating the signature 
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set requires stopping the sensor, updating the signature set, and then restarting 
execution. Some of these tools provide a way to enable/disable some of the 
available signatures, but few systems allow for the dynamic inclusion of new 
signatures at execution time. In addition, the ad hoc nature of existing tools 
does not allow one to dynamically configure a running sensor so that a new 
event stream can be used as input for the security analysis. 

Another limit of existing tools is the relatively static configuration of re- 
sponses. First of all, as for signatures, normally it is possible to choose only from 
a specific subset of possible responses. In addition, to our knowledge, no system 
allows for associating a response with intermediate steps of an attack. This is a 
severe limitation, especially in the case of distributed attacks carried out over a 
long time span. 

Finally, the configuration of existing tools is mainly performed manually and 
at a very low level. This task is particularly error-prone, especially if the intrusion 
detection sensors are deployed across a very heterogeneous environment and 
with very different configurations. The challenge is to determine if the current 
configuration of one or more sensors is valid or if a reconfiguration is meaningful. 

In this paper, we describe a novel approach to distributed intrusion detection. 
The idea is that a protected network is instrumented with a “web of sensors” 
composed of distributed components integrated by means of a local communi- 
cation and control infrastructure. The task of the web of sensors is to provide 
fine-grained surveillance inside the protected network. The web of sensors im- 
plements local surveillance against both outside attacks and local misuse by 
insiders in a way that is complementary to the mainstream approach where a 
single point of access (e.g., a gateway) is monitored for possible malicious activ- 
ity. The outputs of the sensors, in the form of alerts, are collected by a number of 
“meta-sensor” components. Each meta-sensor is responsible for a subset of the 
deployed sensors, and may coordinate its activities with other meta-sensors. The 
meta-sensors are responsible for storing the alerts, for routing alerts to other sen- 
sors and meta-sensors (e.g., to perform correlation to identify composite attack 
scenarios), and for exerting control over the managed sensors. 

Control is the most challenging (and most overlooked) functionality of dis- 
tributed surveillance. Most existing approaches simply aggregate the outputs of 
distributed sensors and focus mainly on the intuitive presentation of alerts to the 
network security officer. This is just not enough. There is a need for fine-grained 
control of the deployed sensors in terms of scenarios to be detected, tailoring 
of the sensors with respect to the protected network, and dynamic control over 
the types of response. These are requirements that can be satisfied only if the 
surveillance sensors are highly configurable and configuration can be performed 
dynamically, without stopping and restarting sensors when a reconfiguration is 
needed. 

We have designed a suite of highly configurable surveillance sensors and a 
command and control meta-sensor that allows the network security officer to 
exert a very fine-grained control over the deployed surveillance infrastructure. 
Meta-sensors can be organized hierarchically to achieve scalability and can be 
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replicated to support fault-tolerance. This web of sensors is built around the 
State Transition Analysis Technique (STAT) framework developed by the Re- 
liable Software Group at UCSB. The STAT framework provides a platform for 
the development of highly configurable probes in different domains and envi- 
ronments. The STAT approach is centered around five key concepts: the STAT 
technique, the STATL language, the STAT Core, the CommSTAT communica- 
tion infrastructure, and the MetaSTAT control system. 

The approach provides the basic mechanisms to reconfigure, at run-time, 
which input event streams are analyzed by each sensor, which scenarios have 
to be used for the analysis, and what types of responses must be carried out 
for each stage of the detection process. In addition, the approach models ex- 
plicitly the dependencies among the modules composing a sensor so that it is 
possible to identify automatically the steps that are necessary to perform a re- 
configuration of the deployed sensing infrastructure. In addition, the possibility 
of retrieving current configurations from remote sensors allows one to determine 
if a reconfiguration is valid or meaningful. 

The remainder of the paper is structured as follows. Section |21 presents the 
fundamental elements of the STAT approach. Section 0 describes the structure 
of STAT-based sensors. Section 0 discusses the dependencies between modules 
and the concept of a valid and meaningful configuration. Section 0describes how 
dependencies are used during the reconfiguration process. Section 0 draws some 
conclusions and outlines future work. 



2 The STAT Framework 

The STAT framework is the result of the evolution of the original STAT tech- 
nique and its application to UNIX systems [blbl/j into a general framework for 
the development of STAT-based intrusion detection sensors 0. 

The STAT Technique. STAT is a technique for representing high-level descrip- 
tions of computer attacks. Attack scenarios are abstracted into states, which 
describe the security status of a system, and transitions, which model the evo- 
lution between states. By abstracting from the details of particular exploits and 
by modeling only the key events involved in an attack scenario STAT is able to 
model entire classes of attacks with a single scenario, overcoming some of the 
limitations of plain signature-based misuse detection systems 0- 

The STATL Language. STATL is an extendible language nm that is used to 
represent STAT attack scenarios. The language defines the domain-independent 
features of the STAT technique. The STATL language can be extended to ex- 
press the characteristics of a particular domain and environment. The extension 
process includes the definition of the set of events that are specific to the partic- 
ular domain or environment being addressed and the definition of new predicates 
on those events. For example, to extend STATL to deal with events produced 
by the Apache Web browser one would define one or more events that represent 



72 



G. Vigna, R.A. Kemmerer, and P. Blix 



entries in the application logs. In this case an event would have the fields host, 
ident, authuser, date, request, status, and bytes as defined by Apache’s 
Common Log Format (CLF) After having defined new events it may be 
necessary to specify specific predicates on those events. For example, the predi- 
cate isCGIrequest 0 would return true if an event is a request for a CGI script. 
Event and predicate definitions are grouped in a language extension. Once the 
event set and associated predicates for a language extension are defined, it is 
possible to use them in a STATE scenario description by including them with 
the STATE use keyword. A number of extensions for TCP/IP networks. Sun 
BSM audit records and Windows NT event logs have been developed. 

STATE scenarios are matched against a stream of events by the STAT core 
(described below). In order to have a scenario processed by the STAT core it is 
necessary to compile it into a scenario plugin, which is a shared library (e.g., 
a “.so” library in EINIX or a DLL library in Windows). In addition, each lan- 
guage extension used by the scenario must be compiled into an extension module, 
which is a shared library too. Both STATE scenarios and language extension are 
translated into C-|— I- code and compiled into libraries by the STAT development 
tools. 

The STAT Core. The STAT core represents the runtime of the STATE language. 
The STAT core implements the domain-independent characteristics of STATE, 
such as the concepts of state, transition, timer, matching of events, etc. At run- 
time the STAT core performs the actual intrusion detection analysis process by 
matching an incoming stream of events against a number of scenario plugins. A 
running instance of the STAT core is dynamically extended to build a STAT- 
based sensor, as described in Section El 

The CommSTAT communication infrastructure. STAT-based sensors are con- 
nected by a communication infrastructure that allows the sensors to exchange 
alert messages and control directives in a secure way. CommSTAT messages fol- 
low the standard Intrusion Detection Message Exchange Format (IDMEF) m 
The original IDMEF definition includes the two events Heartbeat and Alert. 
This original set of events has been extended to include STAT-related control 
messages that are used to control and update the configuration of STAT-sensors. 
For example, messages to ship a scenario plugin to a remote sensor and have it 
loaded into the core have been added (x-stat-scenario-activate), as well as 
messages to manage language extensions and other modules (the message names 
are all prefixed with x-stat-, following the extension guidelines of the IDMEF 
format). Participation in the CommSTAT communication infrastructure is me- 
diated by a CommSTAT proxy that performs preprocessing of messages and 
control directives and that supports the integration of third-party tools that are 
not based on the STAT framework. 

The MetaSTAT control infrastructure. The CommSTAT communication infras- 
tructure is used by the MetaSTAT component to exert control over a set of 
sensors. The MetaSTAT component is responsible for the following tasks: 
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Fig. 1. Architecture of a web of sensors. 



— Collect and store the alerts produced by the managed sensors. 

IDMEF alerts are stored in a MySQL relational database. A schema to 
efficiently store and retrieve IDMEF alerts has been developed, and a GUI 
for the querying and display of stored alerts has been implemented. 

— Route alerts to STAT sensors and other MetaSTAT instances. 
MetaSTAT components and STAT-based sensors can subscribe for specific 
alerts. Alerts matching a subscription are routed through the appropriate 
CommSTAT communication channels. 

Maintain a database of available modules and relative dependen- 
cies. Each MetaSTAT component is associated with a Module Database of 
compiled scenario plugins, language extension modules, and other modules 
that will be discussed later. For each module, the database stores the depen- 
dencies with respect to both other modules and the operational environment 
where the module may need to be deployed. These dependencies are a novel 
aspect of the STAT approach and are described in more detail in Section 01 

— Maintain a database of current sensor configurations. MetaSTAT 
manages a Sensor Database containing the current components that are ac- 
tive or installed at each STAT-based sensor. This “privileged” view of the 
deployed web of sensors is the basis for controlling the sensors and plan- 
ning reconfigurations of the surveillance infrastructure. The structure of the 
database is described in detail in Sectional 

The high-level view of the architecture of the STAT-based web of sensor is 
given in Figure ^ The following sections discuss the structure of a single STAT- 
based sensor and how its reconfiguration is performed through a MetaSTAT 
component. 
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3 STAT Sensors 

STAT sensors are intrusion detection systems that perform localized security 
analysis of one or more event streams (operating system audit records, network 
traffic, application logs, system calls, etc.). 




(a) Bare Sensor 

Sensor 





^^l^guage Extension 

library 

Event Provider library 

(b) Sensor with Event Provider 
Sensor 




Response Functions 



(c) Sensor with Scenario Plugin 



(d) Scenario Plugin with Responses 



Fig. 2. Evolution of a STAT-based sensor. 



The architecture of a STAT-based sensor is centered around the STAT core 
(see Figure The STAT core is extended with a number of modules that, 
together, determine the sensor’s intrusion detection capabilities and behavior. 
The configuration of a STAT sensor can be changed at run-time through control 
directives sent by the MetaSTAT component responsible for the sensor. A set of 
initial modules can be (and usually is) defined at startup time to determine the 
initial configuration of a sensor. In the following, an incremental configuration of 
a STAT-based sensor will be described to better illustrate the role of each sensor 
module, provide a hint of the high configurability of sensors, and describe the 
dependencies between the different modules. 

When a sensor is started with no modules, it contains only an instance of 
the STAT core waiting for events to be processed. The core is connected to a 
CommSTAT proxy, which, in turn, is connected to a MetaSTAT instance. This 
initial “bare” configuration, which is presented in FigureO(a)j does not provide 
any intrusion detection functionality. 

The first step is to provide a source of events. To do this, an event provider 
module must be loaded into the sensor. An event provider collects events from 
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the external environment (e.g., by parsing the Apache server logs, or by obtaining 
packets from the network driver) , creates events as defined in one or more STAT 
language extensions (e.g., the Apache language extension), encapsulates these 
events into generic STAT events, and inserts these events into the input queue 
of the STAT core. Event providers can be dynamically added to and removed 
from a STAT core, and more than one event provider can be active at one time. 
For example, both an event provider for Apache events and a Solaris BSM audit 
record provider may feed their event streams to the same core. An event provider 
is implemented as a shared library. The activation of an event provider is done 
through MetaSTAT by requesting the shipping of the event provider shared 
library to the sensor and then requesting its activation. An event provider relies 
on the event definitions contained in one or more language extension modules. If 
these are not available at the sensor’s host, these have to be shipped there as well. 
Once both the event provider and the language extensions are available at the 
remote host, the event provider is activated. As a consequence, a dedicated thread 
of execution is started to execute the event provider. The provider collects events 
from the external source, filters out those that are not of interest, transforms 
the remaining events into event objects (as defined by the language extension), 
encapsulates them into generic STAT events, and then inserts them into the core 
input queue. The core, in turn, consumes the events and checks if there are any 
STAT scenarios interested in the specific event types. At this point, the core is 
empty, and therefore no actual processing is carried out. This configuration is 
described in Figure El (b). 

To start doing something useful, it is necessary to load one or more scenario 
plugins into the core. To do this, first a scenario plugin module, in the form 
of a shared library, is transferred to the sensor’s host. A plugin may need the 
functions of one or more language extension modules. If these are not already 
available at the destination host then they are shipped there as well. Once all 
the necessary libraries have been transferred to the sensor’s host, the plugin is 
loaded into the core, specifying a set of initial parameters. When a plugin is 
loaded into the core an initial prototype for the scenario is created. The scenario 
prototype contains the data structures representing the scenario’s definition in 
terms of states and transitions, a global environment, and a set of activation 
parameters. The prototype creates a first instance of the scenario. This instance 
is in the initial state of the corresponding attack scenario. The core analyzes the 
scenario definition and subscribes the instance for the events associated with the 
transitions that start from the scenario’s initial state. 

At this point the core is ready to perform event processing. The events ob- 
tained by the provider are matched against the subscriptions of the initial in- 
stance. If an event matches a subscription, then the corresponding transition 
assertion is evaluated. If the assertion is satisfied then the destination state as- 
sertion is evaluated. If this assertion is also satisfied then the transition is fired. 
As a consequence of transition firing the instance may change state or a new in- 
stance may be created. Each scenario instance represents an attack in progress. 
The details of scenario processing are described elsewhere 0. This situation is 
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presented in Figure|3 (c), where a scenario plugin has been loaded and there are 
currently four active instances of the scenario. 

As a scenario evolves from state to state, it may produce some output. A 
typical case is the generation of an alert when a scenario completes. Another 
example is the creation of a synthetic event. A synthetic event is a STAT event 
that is generated by a scenario plugin and inserted in the core event queue. The 
event is processed like any other event and may be used to perform forward 
chaining of scenarios. 

Apart from logging (the default action when a scenario completes) and the 
production of synthetic events (that are specified internally to the scenario def- 
inition), other types of responses can be associated with scenario states using 
response modules. Response modules are collections of functions that can be used 
to perform any type of response (e.g., page the administrator, reconfigure a fire- 
wall, or shutdown a connection). Response modules are implemented as shared 
libraries. To activate a response function it is necessary to transfer the shared 
library containing the desired response functionality to the sensor’s host, load 
the library into the core, and then request the association of a function with a 
specific state in a scenario definition. This allows one to specify responses for any 
intermediate state in an attack scenario. Each time the specified state is reached 
by any of the instances of the scenario, the corresponding response is executed. 
Responses can be shipped, loaded, activated, and removed remotely through the 
MetaSTAT component. Figure 0(d) shows a response library and some response 
functions associated with particular states in the scenario definition. 

At this point, the sensor is configured as a full-fledged intrusion detection 
system. Event providers, scenario plugins, language extensions, and response 
modules can be loaded and unloaded following the needs of the overall intrusion 
detection functionality. As described above, these reconfigurations are subject to 
a number of dependencies that must be satisfied in order to successfully load a 
component into the sensor and to have the necessary inputs and outputs available 
for processing. These dependencies are managed by the MetaSTAT component, 
and they are discussed in the next section. 

4 Module Dependencies and Sensor Configurations 

The flexibility and extendibility supported by the STAT-based approach is a ma- 
jor advantage: the configuration of a sensor can be reshaped in real-time to deal 
with previously unknown attacks, changes in the site’s policy, different levels 
of concern, etc. Fine-grained configurability requires careful planning of module 
installation and activation. This activity can be very complex and error-prone if 
carried out without support. For this reason the MetaSTAT component main- 
tains a database of modules and their associated dependencies and a database of 
the current sensor configurations. These databases provide the support for con- 
sistent modifications of the managed web of sensors. In the following, the term 
module is used to denote event providers, scenario plugins, response modules, 
and language extensions. The term external component is used to characterize 



Designing a Web of Highly-Configurable Intrusion Detection Sensors 



77 



some host facility or service that is needed by an event provider as a source 
of raw events or by a response function to perform some action. These compo- 
nents are outside the control of MetaSTAT. For example, a BSM event provider 
needs the actual BSM auditing system up and running to be able to access audit 
records and provide events to the STAT core. 

Dependencies between modules can be classified into activation dependen- 
cies and functional dependencies. Activation dependencies must be satisfied for 
a module to be activated and run without failure. For example, consider a sce- 
nario plugin that uses predicates defined in a language extension. The language 
extension must be loaded into the core before the plugin is activated. Otherwise, 
the plugin activation will fail with a run-time linking error. Functional depen- 
dencies are associated with the inputs of a module. The functional dependencies 
of a module are satisfied if there exist modules and/or external components that 
can provide the inputs used by the module. Note that a module can success- 
fully be activated without satisfying its functional dependencies. For example, 
suppose that a scenario plugin that uses BSM events has been successfully acti- 
vated, but there is no BSM event provider to feed the core with BSM events. In 
this case, the scenario is active but completely useless. The inputs and outputs 
of the different module types, and the relative dependencies are summarized in 
Tabled 

Table 1. Input and output, and dependencies of STAT sensor modules. 



Module 


Inputs 


Outputs 


Activation Deps 


Functional Deps 


Event Provider 


External 
event stream 


STAT events 


Extension modules 


External compo- 
nents 


Scenario Plugin 


STAT events, 

synthetic 

events 


Synthetic 

events 


Extension modules 


Scenario plugins. 
Event providers 


Response Module 


Parameters 
from plugin 


External 

response 


Extension modules 


External compo- 
nents 


Language Exten- 
sion 


None 


None 


Extension modules 


None 



Information about dependencies between modules is stored in MetaSTAT’s 
Module Database. The schema of the Module Database is shown in Figure El 
The functional dependencies for a module are partly modeled implicitly by 
matching the inputs required by the module with the outputs provided by some 
other module. Determining the functional dependencies on other modules re- 
quires that two queries be made on the Module Database. The first query gets 
the inputs required by the module from the Module Input table. The second 
query examines the Module Output table to determine which modules are gen- 
erating the inputs that were returned from the first query. The results returned 
from the second query identify the modules that satisfy the functional depen- 
dencies of the original module. The functional dependencies on external compo- 
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Fig. 3. Schema for the Module Database. 



nents are modeled explicitly by the Functional Dependency table. In addition 
to dependencies, the Module Database also stores information such as version, 
OS/architecture compatibility information, etc. 

The Module Database is used by MetaSTAT to automatically determine the 
steps to be undertaken when a sensor reconfiguration is needed. Since sensors 
do not always start from a “bare” configuration, as shown in Figure El (a) , it 
is usually necessary to modify an existing sensor configuration. Therefore, the 
MetaSTAT component maintains a second database called the Sensor Database, 
which contains the current configuration for each sensor. A visualization of the 
Sensor Database schema is given in Figure El 

To be more precise, the term configuration is defined as follows: A STAT sen- 
sor configuration is uniquely defined by a set of installed and activated modules 
and available external components. The term installed is used to describe the 
fact that a module has been transferred to and stored on a file system accessible 
by the sensor and in a location known by the sensor. The term activated is used 
to describe the fact that a module has been dynamically loaded in a sensor as 
the result of a control command from MetaSTAT. The term loaded has the same 
meaning as activated in relation to language extension modules. 



Designing a Web of Highly-Configurable Intrusion Detection Sensors 



79 




Fig. 4. Schema for the Sensor Database. 



A configuration can be valid and/or meaningful. A configuration is valid if 
all activated modules have all their activation dependencies satisfied. A configu- 
ration is meaningful if the configuration is valid and all functional dependencies 
are also satisfied. 



5 Automated Support for Sensor Reconfigurations 

MetaSTAT uses the databases described in the previous section to assist the 
Intrusion Detection Administrator (IDA) in reconfiguring a web of sensors. To 
better describe the operations involved in a reconfiguration and the support 
provided by MetaSTAT, an example will be used. 

Suppose that the IDA noted or was notified of some suspicious FTP activity 
in a subnetwork inside hi^ organization. Usually, the IDA would contact the 
responsible network administrator and would ask him0 to install and/or acti- 
vate some monitoring software to collect input data for further analysis. The 
IDA might even decide to login remotely to particular hosts to perform manual 
analysis. Both activities are human-intensive and require a considerable setup 
time. 

MetaSTAT supports a different process in which the IDA interacts with a 
centralized control application (i.e., the MetaSTAT console) and expresses his 
interest in having the subnetwork checked for possible FTP-related abuse. This 
request elicits a number of actions: 



^ By “his” we mean “his or her”. 
^ By “him” we mean “her”. 
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1. The scenario plugins contained in the Module Database are searched for 
the keyword “FTP” . More precisely the IDA’s request is translated into the 
following SQL query: 

SELECT module_id, name, os_platform, description 
FROM Module_Index 

WHERE (name LIKE ’“/.ftp"/.’ DR description LIKE ’"/.ftp”/.’) 

AND type="plugin" ; 



The following information is returned: 



module.id 


name 


os.platf orm 


description 


module.l 


wu-f tpd-bovf 


Linux 


X86 


BOVF attack against ftpd 


module.2 


ftpd-quote-abuse 


Linux 


X86 


QUOTE command abuse 


module.9 


ftpd-protocol-verify 


Linux 


X86 


FTP protocol verifier 



The IDA selects the wu-ftp-bovf and ftpd-quote-abuse scenario plugins 
for installation. 

2. The Module Database is examined for possible activation dependencies. The 
wu-ftp-bovf activation dependencies are determined by the following query: 

SELECT dep_moduIe_id FROM Activation_Dependency 
WHERE moduIe_id="moduIe_l" ; 



The query results (not shown here) indicate that the scenario plugin requires 
the ftp language extension. This is because events and predicates defined 
in the ftp extension are used in states and transitions of the wu-ftp-bovf 
scenario. A similar query is performed for the ftpd-quote-abuse scenario 
plugin. The query results indicates that the syslog language extension is 
required by the plugin. 

3. The Module Database is then searched for possible functional dependencies. 
For example in the case of the wu-ftp-bovf scenario the following query is 
executed: 

SELECT input_id FROM ModuIe_Input WHERE moduIe_id="moduIe_l" ; 



The query returns an entry containing the value FTP .PROTOCOL. This means 
that the wu-ftp-bovf scenario uses this type of event as input. Therefore, 
the wu-ftp-bovf scenario plugin has a functional dependency on a module 
providing events obtained by parsing the FTP protocol. A similar query 
indicates that the ftpd-quote-abuse plugin has a functional dependency 
on a provider of SYSLOG events. 

4. These new requirements trigger a new search in the Module Database to find 
which of the available modules can be used to provide the required inputs. 
SYSLOG events are produced by three event providers: syslogl, sysIog2, 
and win-app-event. The FTP. protocol events are produced, as synthetic 
events, by the ftp-protocol-verify scenario. 
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wu-f tp-bovf 
scenario 




ftp 
lang ext 



FTP PROTOCOL 

event 



O 



♦ 

f tp-protocol-verify 




ftp tcpip 

lang ext lang ext 



tcpip 
lang ext 



STREAM 

event 



I 



netproc 
event provider 



network-driver 



external component 



ftpd- quote- abuse 
scenario 

V 



syslog 
lang ext 



SYSLOG 




syslogl 
event provider 




syslog 
lang ext 



syslog2 
event provider 

i 

syslog 
lang ext 




win-app-event 
event provider 




winevent NTlogging 
lang ext external component 



syslogd syslogd 

external component external component 



Fig. 5. Dependency graph for scenarios wu-ftp-bovf and ftpd-quote-abuse. In the 
hgure, arrows marked with the letter “A” are used to represent activation dependencies. 
Arrows marked with “I” represent the relationship between a module and the input 
events required. Arrows marked with an “O” represent the relationship between an 
event type and the module that produce that type of event as output. Arrows marked 
with “E” represent a dependency on an external component. 



5. Both the syslogl and syslog2 event providers require an external source, 
which is the syslog facility of a UNIX system. In particular, syslog2 is 
tailored to the syslogkd daemon provided with Linux systems. Both event 
providers have an activation dependency on the syslog language exten- 
sion. The win-app-event event provider is tailored to the Windows NT 
platform. It depends on the NT event log facility (as an external compo- 
nent) and relies on the NT event log language extension (winevent). The 
ftp-protocol-verify is a network-based scenario and, as such, requires a 
network event provider that produces events of type STREAM, which are events 
obtained by reassembling TCP streams. The scenario has two activation de- 
pendencies; it needs both the tcpip and the ftp language extensions. The 
first is needed because STREAM events are used in the scenario’s transition 
assertions. The second is needed to be able to generate the FTP_protocol 
synthetic events. 

6. Events of type STREAM are produced by an event provider called netproc. 
This event provider is based on the tcpip language extension, and requires, 
as an external component, a network driver that is able to eavesdrop traffic. 

7. At this point, the dependencies between the modules have been determined 
(see Figure El). The tool now identifies the sensors that need to be reconfig- 
ured. This operation is done by querying the Sensor Database to determine 
which hosts of the network under exam have active STAT-based sensors. 
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The query identifies two suitable hosts. Host lucas, a Linux machine, has a 
bare sensor installed. Host spielberg, another Linux machine, runs a STAT- 
based sensor equipped with the netproc event provider, the tcpip language 
extension, and some scenario plugins. Both hosts provide the network driver 
and UNIX syslog external component. The tool decides (possibly with help 
from the IDA) to install the ftpd-quote-abuse scenario on lucas and the 
wu-ftp-bovf scenario on spielberg. 

8. The syslog language extension is sent to lucas, and it is installed in the 
file system. This is done using the following CommSTAT messages: 

<x-stat-extension-lib-install id=" 1"> 

<extension_lib name=" syslog" version="1.0. 1"> 

[... encoded library ...] 

</ extension-lib> 

</x-stat-extension-lib-install> 

<x-stat-extension-lib-activate id="2"> 

<extension_lib name=" syslog" version="1.0. 1"> 
</extension-lib> 

</x-stat-extension-lib-activate> 

The syslog2 event provider is sent, installed, and loaded in the sensor by 
means of similar commands. At this point syslog events are being fed to the 
core of the sensor on host lucas. The ftpd-quote-abuse scenario plugin is 
sent to the host, installed on the file system, and eventually loaded into the 
core. 

9. The ftp language extension is sent to host spielberg. The tcpip language 
extension is already available, as is the netproc event provider. There- 
fore, the ftp-protocol-verif y scenario plugin can be shipped to host 
spielberg, installed, and loaded into the core. The scenario starts parsing 
STREAM events and producing FTP_PR0TDC0L synthetic events. As the final 
step, the wu-ftpd-bovf scenario is shipped to host spielberg, installed, 
and loaded into the core, where it immediately starts using the synthetic 
events generated by the ftp-protocol-verify scenario. 

After the necessary reconfigurations are carried out the IDA may decide to 
install specific response functions for the newly activated scenarios. A process 
similar to the one described above is followed. Response modules, in the form 
of shared libraries, may be shipped to a remote host and linked into a sensor. 
Additional control commands may then be used to associate states in a scenario 
with the execution of specific functions of the response module. 

6 Conclusions and Future Work 

Many research and commercial intrusion detection systems implement their in- 
trusion detection functionality using a distributed set of sensors. The advantages 
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of this approach are obvious, but these systems suffer from a number of limita- 
tions mainly related to their configurability. 

For example, it is not possible to add new event sources to existing sen- 
sors; it is difficult, if not impossible, to create, ship, and load new signatures 
at run-time; and responses are usually predefined or chosen from a predefined 
set. We have implemented a set of components and a control infrastructure that 
overcome these limits. The STAT-based framework has been leveraged to realize 
a highly-configurable “web of sensors” controlled by a meta-sensor component, 
called MetaSTAT. The flexibility of the framework allows the Intrusion Detection 
Administrator to perform complex reconfiguration tasks. In addition, by explic- 
itly modeling the dependencies between modules it is possible to automatically 
generate a valid deployment plan from high-level specifications. 

The “web of sensors” is based on the STAT approach but it has been designed 
to be open. Third party IDS modules can easily be integrated through Comm- 
STAT proxies. Integration of external components is limited to the exchange of 
alerts if primitives for the dynamic configuration of sensors are not available. 

The STAT framework and the core component have been designed and imple- 
mented. The STAT framework has been used to build a number of IDSs, includ- 
ing two systems for host-based intrusion detection in UNIX and Windows NT en- 
vironments, called USTAT and WinSTAT, respectively jblUTj . a network-based 
intrusion detection system called NetSTAT HM, and a distributed event ana- 
lyzer called NSTAT Two of the systems, namely USTAT and NetSTAT, have 
been used in four different DARPA-sponsored evaluations ITTira . The Comm- 
STAT communication infrastructure has been completed and distributed to the 
intrusion detection community through the IETF idwg mailing list. A first pro- 
totype of the MetaSTAT component that collects alerts from multiple sensors 
concurrently, stores them in a MySQL alert database and provides the IDA with 
a graphical viewer has been developed. In addition, database schemas for the 
Module Database and the Sensor Database have been implemented. Most of the 
control primitives have been defined and partially implemented. The MetaSTAT 
component is also lacking the alert routing functionalities. These will be the 
focus of future work. 
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Abstract. This paper describes an aggregation and correlation algo- 
rithm used in the design and implementation of an intrusion-detection 
console built on top of the Tivoli Enterprise Console (TEC). The aggre- 
gation and correlation algorithm aims at acquiring intrusion-detection 
alerts and relating them together to expose a more condensed view of 
the security issues raised by intrusion-detection systems. 

Keywords: Intrusion detection, alert aggregation, alert correlation, 
alert data model. 



1 Introduction 

Intrusion-detection products have become widely available in recent years, and 
are beginning to gain acceptance in enterprises as a worthwhile improvement 
on security. They monitor accesses and data flows in information systems to 
determine whether malicious behavior is taking place, either from outside or 
inside, and make this information available to the operators of the information 
system. In addition, they can also react to malicious behavior and take some 
countermeasures. 

The purpose of this work is to address the following areas of intrusion detec- 
tion, which are known to present weaknesses: 

1. Flooding. Intrusion-detection systems are prone to alert flooding, i.e., they 
provide a large number of alerts to the operator, who then has difflculties 
coping with the load. This problem has been recently highlighted by the 
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release of and IDSwakew^ two tools that flood an intrusion-detection 

system with unrelated alerts, carrying an effective denial-of-service attack 
against the operator if the intrusion-detection system manages to cope with 
the flux of anomalous events. 

2. Context. Attacks are likely to generate multiple related alerts. Current intru- 
sion-detection systems do not make it easy for operators to logically group 
related alerts. 

3. False alerts. Existing intrusion-detection systems are likely to generate false 
alerts, be it false positives or false negatives, for various reasons. For ex- 
ample, attack descriptions (a.k.a. signatures) are often imprecise and also 
cover acceptable behaviors of the monitored information system, or the im- 
plementation does not conform to the specification and known attacks go 
undetected. 

4. Scalability. Current intrusion-detection system architectures make it difficult 
to achieve large-scale deployment. 

The outline of this paper is as follows. Section 2 describes a generic and 
scalable intrusion-detection architecture and introduces the concept of an ag- 
gregation and correlation component (ACC) that can analyze and correlate the 
alerts generated by intrusion-detection probes attached to it. In Section 3, we 
list the conceptual and operational requirements this ACC has to fulfill. Section 
4 describes our architecture for alert processing as well as the unified alert data 
model we use. In Section 5, we discuss the aggregation and correlation algorithm 
that we have implemented in our prototype system, and in Section 6 we give 
a usage example. Section 7 contains the conclusions and offers ideas for future 
work. 



2 A Generic, Scalable Intrusion-Detection Architecture 

In the current state of intrusion-detection technology, we wish to distinguish be- 
tween two kinds of components, the probes and the aggregation and correlation 
components (ACCs). What we call intrusion-detection probes in this context are 
usually referred to as intrusion-detection systems available either as commercial 
products or in the public domain. The purpose of the ACC is to correlate the 
output of several probes and give the operator a condensed view of the reported 
security issues. In the past few years, intrusion-detection research focussed on 
developing new probes or improving the technology behind existing ones. How- 
ever, when a set of probes is deployed in large environments, the correlation 
problem becomes apparent. Thus far, aggregation and correlation have not been 
addressed by intrusion-detection product developers and are only now gaining 
momentum in the research community. 

The relationship between probes and ACCs is shown in Figure d As one can 
see, the architecture is a distributed set of components, hierarchically layered to 
enable scalability of the whole system. 

^ http:/ /www. eurocompton.net/stick/projects8.html 
^ http:/ /www. hsc.fr/ressources/outils/idswakeup/ 
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Fig. 1. Overall intrusion-detection architecture. 



We have implemented a prototype of an ACC that is based on the Tivoli 
Enterprise Console (TEC) [4I7| . The TEC is the event-handling product of 
IBM/Tivoli Systems. Based on our technology, there is also a product available 
now, the Tivoli Secure Way Risk Manager m- 



2.1 Probes 

A state-of-the-art review of intrusion-detection systems oriented towards a tax- 
onomy 0 lists many different probes, both host-based (e.g. using data sources 
provided on hosts) and network-based (e.g. tapping into the network traffic to 
retrieve data). 

In our implementation and experiments, we used such probes as Internet 
Security Systems’ RealSecure Network Engin^ and Cisco Systems’ Cisco Secure 
ID^ as well as our own development prototype Weh IDS P and simple, freely 
available tools such as TCP Wrapper [B| and Klaxon. We believe that these 
systems, although extremely useful, face a number of issues as far as large-scale 
deployment and operation are concerned, and that they should be considered as 
part of a larger ensemble rather than as individual solutions to the problem of 
detecting malicious activities against information systems. 

As shown in Figure Q probes are responsible for acquiring data from external 
sources (e.g. audit logs, accounting files, network packets), formatting this data 
to extract the information that is of interest for the analysis mechanism and 
preprocessing it to allow proper analysis. This analysis may lead the probe to 
generate alerts which are transmitted higher up in the architecture. Probes are 

^ http://www.iss.net/ 
http://www.cisco.com/ 
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expected to adhere to the evolving IDWG0 standards for an intrusion-detection 
message exchange format and an intrusion alert protocol. 

Probe implementors need to allocate resources to all functions of the probe. 
In particular, the data formatting, e.g. reassembling network packets or recon- 
structing process activity, can turn out to be very resource intensive. The time 
spent on data formatting is lost for analysis. Therefore, data analysis has to be 
kept simple, which is one reason why probes tend to generate false alerts. 



2.2 Aggregation and Correlation Components (ACCs) 

Each ACC receives alerts from probes and other ACCs. Alerts are sent in a 
standard format and do not need to be altered. Once an alert has been received, 
two sets of tasks are carried out, one to analyze the received alert in the context 
of the ACC (comprising the alerts received earlier and configuration information) 
and one to provide output to the local operator, if any. 

The first set of tasks is covered by the aggregation and correlation algorithm 
described in Section 0 The second set of tasks allows an operator to interact 
with the ACC regardless of where this component is located in the tree. This 
feature accommodates the fact that organizations have multiple reporting levels; 
in our architecture, each department deploying the probes would have at least 
one ACC as well, which would be used for local reporting and for feeding higher- 
level ACCs corresponding to higher levels of the hierarchy. 



3 Requirements 

When we started this project, we had two groups of requirements. Conceptual 
requirements focus on the service that the ACC provides to the operator, in- 
dependently of any implementation considerations. Operational requirements 
describe additional issues that are important but for which we are not yet able 
to provide a generic solution, or issues that are handled on an ad hoc basis. 



3.1 Analysis of the Issues 

This subsection provides a deeper analysis of the issues listed in the introduction, 

and describes the contribution of our ACC towards solving each issue. 

Flooding. One of the most apparent characteristics of intrusion-detection sys- 
tems is that they tend to generate numerous alerts. An operator can be 
flooded with alerts very easily, and the usual reaction is to reduce the flux 
by restricting or even turning off a large part of the signatures that can be 
searched. This behavior is undesirable for two reasons: 

1. The attack may still take place, and disabling signatures may reduce 
the number of false positives but may also increase the number of false 
negatives. Therefore, this approach does not solve the problem. 

® http:/ /www. ietf.org/html.charters/idwg-charter.html 
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2. For reporting, many alerts provide useful information, even though an 
operator may not wish to see them in real time. 

Our ACC intelligently groups alerts together to provide the operator with 
sets of alerts. It offers multi-level views on sets of alerts, and by displaying 
only the most important views, the operator can concentrate on activities 
that could actually lead to successful compromise or denial-of-service. 
Context. An attack is very likely to manifest itself in multiple alerts spread over 
a period of time. A skilled attacker will first probe to evaluate its target and 
then start penetrating, the entire activity being sufficiently widely spread to 
go barely noticed. 

Our ACC groups alerts together to provide an analysis of the entire context, 
not alert-per-alert. This allows the operator to carefully evaluate the progress 
of the attacker and the knowledge he has gained, and to ensure that the 
countermeasures taken are appropriate. 

False alerts. As experience shows, probes tend to generate false alerts that 
are directly related to the particularities of the information system in which 
they are deployed. Given that developers of intrusion-detection systems - by 
trying to avoid false negatives - accept a certain number of false positives, 
this is a frequent issue in today’s systems. Inaccuracy of the alerts in the 
correlation component is considered in two forms: 

1. Intrinsic inaccuracy of the alert owing to the probe’s detection code 
being poorly written such that it does not discriminate well between 
normal and malicious activity for this particular attack. 

2. Relative inaccuracy of the alert owing to the information system being 
monitored exhibiting characteristics similar to those of malicious activi- 
ties. 

Both aspects are taken into account in the ACC by associating each alert 
with a confidence value. This value is determined independently of the prod- 
uct vendor. Default values take into account the intrinsic inaccuracy of the 
alert and should be modified by the operator to consider relative inaccuracy, 
which results in reducing the confidence value. 

Further, our ACC can be configured such that it knows under which circum- 
stances different probes should report the same attack. If an expected alert 
does not arrive at the correlation component, it can be deduced that a probe 
is no longer working properly or does not adhere to its specification. 
Scalability. Given the number of alerts generated by current intrusion- 
detection probes, scalability rapidly becomes an issue. When deploying a 
larger number of probes, operators are forced to reduce the number of vul- 
nerabilities monitored to limit the number of alerts to a reasonable level. 
Our ACC distributes the load of handling alerts to the appropriate level in 
the hierarchy of any organization. 

Of course, some of these issues could be solved at the probe level. For example, 
by writing better signatures many false alerts could be avoided. Although we 
expect to see better probes in the future, there will be issues that are site- 
specific or are not addressed perfectly by the probes. Therefore, we think that 
the ACC has to address all the four issues listed above. 
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3.2 Conceptual Requirements 

The conceptual requirements focus on the semantic of the information that is 
provided to operators, on the scalability of the entire intrusion-detection system, 
on the reactivity, and on the proactivity that must be achieved to make such a 
system usable. 

Semantics. One of the main issues that prevents large-scale deployment of 
intrusion-detection probes is the level of information they generate. Intru- 
sion-detection alerts are very low-level bits of information from which it 
is difficult to obtain a global picture. The requirement on our ACC is to 
present one alert per attack, even if this attack has generated many alerts. 
It must thus present the most concise picture for each attack, while providing 
as much information as possible. This includes aggregating and correlating 
from as many sources as possible to ensure that no false alert is raised to 
the operator. 

To satisfy this requirement, we have developed the concept of situations, 
described in Section |^1 

Scalability. Trade-offs have to be made between information collection and 
system performance. In environments with a large number of probes, a single 
ACC is easily overflooded. 

In our architecture, multiple ACCs can be deployed, each of them handling a 
set of probes on a topological or logical basis. These correlation components 
in turn report to a master in a tree structure. As many layers of ACCs as 
needed can be introduced to handle the required number of probes. Each 
ACC provides an interface for local reporting, and sends data to the upper 
layer. 

Reactivity. The ACC must at least allow and better manage the reaction to 
an intrusion by: 

— automatically gathering more information (e.g. raw logs, audit session, 
nslookup host, finger user). Being integrated with a network management 
platform allows the ACC to make use of the network topology or available 
discovery services; 

— automatically modifying the setup of the intrusion-detection probes. 
This includes modifying the configuration of downstream reasoning en- 
gines in a distributed correlation setting; 

— automatically escalating and warning the appropriate person; 

— automatically applying appropriate countermeasures. 

Our ACC has the potential and the mechanisms to enable automatic coun- 
termeasures. However, this part is still work in progress, as automatic coun- 
termeasures introduce a high risk of self-inflicted denial-of-service attacks. 
Proactivity. The ACC must be able to proactively expect intrusion-detection 
alerts according to the current flow of alerts or according to the time of day. 
For example, routine vulnerability assessment scans are usually scheduled 
periodically. 

Our ACC can be configured to expect such scans and provide an alert if the 
scan does not take place. The same mechanism applies time constraints to 
series of alerts; frequently, sequences of alerts can be shown to correspond to 
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automated, information-system specific behavior. Once these sequences have 
been identified, they can be canceled out by the ACC, and only anomalies 
in the sequence chains are reported. 



3.3 Operational Requirements 

These requirements focus on the interaction of the entire intrusion-detection sys- 
tem (probes and ACCs) with the management platform. As such, the intrusion- 
detection system must integrate with the management platform, and ensure an 
easy configuration and a certain level of performance. 

Integration. We believe that in its current state, intrusion-detection systems 
impose an additional burden on operators to deploy, configure and maintain. 
Integration into an existing framework will give operators a familiar look- 
and-feel, and allow them to use intrusion detection like any other application 
in their realm. 

Our prototype is implemented on top of the Tivoli Enterprise Console (TEC), 
a commercial event-handling product. It takes advantage of the existing fa- 
cilities for event acquisition, storage in a database and display. The ACC is 
implemented as a set of prolog rules for the prolog engine that sits inside the 
TEC and processes events. 

Configurability. The ACC must allow an easy reconfiguration of the reason- 
ing parameters (i.e. severity, confidence, specific known-bad or known-good 
hosts). This should alleviate but not solve the false-alert problem, as opera- 
tors observing false alerts could reduce the trust or level of the corresponding 
alerts, so that their weight in the correlation process is lowered accordingly. 
In our prototype, configuration remains manual, by means of configuration 
files. 

Performance. Network management environments are often capable of han- 
dling hundreds of alerts per second. However, given the complexity of the 
processing required to achieve meaningful correlation and the diversity of 
information contained in the alerts, it is difficult for an ACC to achieve 
the same performance. Therefore, ACCs have to be carefully designed and 
implemented so that they offer optimal performance P]. 

Our ACC is developed with the target of handling one alert per second. This 
corresponds to the maximum alert rate we observe in the environment for 
which our prototype was built. 



4 Representation of Alerts 

The first task we faced when developing the ACC was to develop a unified 
framework for intrusion-detection alerts that would allow us to process them 
regardless of their origin. This led to the definition of a system architecture to 
gather alerts and the definition of a data model in the form of a class hierarchy. 
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4.1 System Architecture 

The ACC acquires alerts from the intrusion-detection probes as shown in Figure 
El We distinguish between two kinds of probes, Tivoli-aware and not. 

A Tivoli-aware probe can send events directly to the Tivoli Enterprise Con- 
sole (TEC); our architecture in this case assumes that the probe also knows the 
data model and the appropriate format for events. An example of such a probe 
is Web IDS |01. 

A non-Tivoli-aware probe requires an additional interface component to real- 
ize the transformation of native events into our data model. This probe-specific 
interface component is called a pre-adapter. It runs on the probe and knows how 
to read alert information in real time (or as close to it as possible). It formats 
the alert according to the alert class hierarchy described in Section ^21 It then 
ships this formatted alert using the Tivoli Framework communication facility to 
the TEC where the ACC is implemented. Currently, the pre-adapter has no ad- 
ditional function. However, if performance becomes an issue, we envisage giving 
it more functionality, such as providing alert counts, to reduce the workload of 
the ACC. 

Note that alerts are defined in both places: in the probe or the pre-adapter 
and in the TEC. If the two do not match, the alerts will not be processed by the 



Aggregation and Correlation of Intrusion-Detection Alerts 



93 



correlation rules. Also note that this architecture does not prevent us from using 
the standard event sources (e.g. syslog) already found in information systems. 
Additional adaptation can be performed by the ACC, with some performance 
cost (see Section 



4.2 Alert Class Hierarchy 

One of the main challenges of this work was the creation of a unified data model 
for acquiring intrusion-detection alerts. This data model is vital to the project 
for two reasons: ensuring independence between the correlation algorithms and 
the actual alerts generated by the probes, and ensuring that any probe can easily 
be integrated into the system and benefit from the generic correlation rules. The 
data model deployed in our prototype was also used as the basis of the IDWG 
work on a standard message-exchange format. 

There are two kinds of classes. Abstract classes represent generic alert con- 
cepts that can be used by all intrusion-detection probes. Implementation classes 
inherit from abstract classes and carry specific alerts generated by a specific 
probe. The design of the abstract classes is partially shown using UML notation 
in Figure 01 

The abstract classes hierarchy heavily uses the inheritance relationship pro- 
vided by object-oriented design methods. This inheritance mechanism provides 
a very strong structure to the model and prevents ambiguities when deciding 
where an implementation class for an alert belongs in the hierarchy. 

The model is data-driven, which means that specialized classes must provide 
more information than the more general classes from which they are derived; in 
practice this translates into adding attributes to the derived classes. 

The data model is roughly organized in layers to facilitate understanding, 
illustrated as shaded boxes in Figure 0 They are described from top to bottom. 

Probe layer. The probe layer carries information about the probe itself (pri- 
marily error or configuration messages) as well as very generic information 
about the alert, e.g., a short alert description or the time stamp of the alert. 
Target layer. The target layer ensures that all alerts instantiated by a class 
inheriting from this level include target information, i.e. the identification 
of one or multiple hosts that are the possible victims of an attack. When 
the alert reports that multiple hosts are targets of the attack, at least a 
headcount is provided. 

Source layer. The source layer ensures that all alerts instantiated by a class 
inheriting from this level include source information, i.e. some identification 
of the host from which the attack appears to be launched. We distinguish 
between two kinds of sources, real and spoofed sources. Real unfortunately 
does not mean that the source of the attack is identified reliably; it simply 
means that there are no indications of obvious spoofing. Spoofed on the other 
hand is used only when the attack by construction requires IP spoofing. 

We expect most alerts to provide at least this level of detail. In fact, 90% of 
the alerts we generate inherit from children of the ES-RealOrigin class. 
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Fig. 3. Description of the alert class hierarchy. 



Detailed target layer. At this layer, detailed information is provided about 
the target. In particular, additional information such as email addresses, 
URLs, and ICMP information is provided by classes defined at this layer. 

To give a better idea of the complexity of the data model, there are about 45 
abstract classes, 175 implementation classes for the RealSecure preadapter and 
80 for the Cisco Secure IDS pre-adapter. 
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5 The Aggregation and Correlation (AC) Algorithm 

The goal of the aggregation and correlation algorithm is to form groups of alerts 
by creating a small number of relationships that are exposed to the operator, 
instead of exposing the raw alerts. The ACC uses two different kind of relation- 
ships: 

Correlation relationship. The algorithm creates correlation relationships be- 
tween related events according to explicit rules programmed into the ACC 
or derived by the ACC from configuration information. Once events are in 
a relationship, they are considered part of the same trend of attacks and as 
such they are processed together. There are currently two kinds of correlation 
relationships between events: duplicates and consequences. 

Aggregation relationship. The algorithm groups events together according 
to certain criteria (similar to database views) to compute an aggregated 
severity level. Whereas the individual severity level of each event might not 
be sufficient to warrant specific analysis, the grouping may reveal trends and 
associations that clarify the intentions of the attacker. 

The AC algorithm is applied in steps. It processes first the incoming alert by 
extracting common information, such as source and target host, and tries to find 
a match for these attributes in previous observations. It then creates correlation 
relationships by checking for duplicates and consequences, and finally creates 
the aggregation relationships through the situations. Once the situations have 
been updated, the appropriate alarms are generated, if necessary, and the alert 
is stored in a database. In Secti on s 15 . 1 1 - 15 . ,Sl ea.ch step is described in more detail. 



5.1 Preprocessing of Alerts 

Preprocessing is needed to unify the information available in an alert and pro- 
vides some error checking to verify that the alert does not contain information 
that is obviously wrong, e.g. an invalid time stamp, and would prevent the cor- 
relation algorithm from working correctly. 

Probes identify the source and target of an attack in different ways. In par- 
ticular, network-based systems are very likely to provide IP addresses, whereas 
host-based systems will provide host names. To ensure unique identification of 
these actors, each is assigned a token. The preprocessing translates the informa- 
tion available in the alert into three tokens: probe, SOURCE and target. This 
translation process does not use external information acquisition, such as DNS 
queries, because of the latency involved in retrieving the information, but relies 
on information available in configuration files. 

Each of the three token definitions is separate. This means that if a host 
acts as probe, source and target, it has to be configured three times. If a host 
is not configured, the AC algorithm generates the appropriate token and stores 
whatever information is available in the alert in this token. The original tokens 
were integers assigned via a monotonically increasing function. However, this 
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scheme poses the problem of synchronizing tokens between multiple ACCs in a 
distributed environment. The current token scheme uses the IP address of the 
host as a token. When dealing with multi-homed hosts or name aliasing, one 
IP address needs to be selected as the primary identification token of the host. 
Then, many associations of this token IP address with host names or additional 
alternate IP addresses can be configured to identify the host as a single entity. 

The AC algorithm needs a unified time reference for alerts. This translates 
into the requirement that probes be synchronized. For example, in the current 
implementation we require that the time of the probes does not differ by more 
than two seconds. This does not mean that alerts should arrive in a time-ordered 
way at the ACC, only that their time stamps were generated in the same time 
frame. The AC algorithm keeps the time of the most recent event received and 
updates this time as events arrive. When a large difference between this “most 
recent” time and the time of the current event is observed, the AC algorithm can 
underevaluate the severity of events. This is abnormal and the ACC generates a 
warning message. In this case, the “most recent” date is reset to the time of the 
last alert received. 

In addition, the normalization process provides mechanisms for translating 
well-known service names into port numbers and vice versa. 



5.2 The Correlation Relationship: Duplicates and Consequences 

This part of the AC algorithm deals with alerts that are logically linked with 
each other. The reasoning is separated into two parts. First, a backward-looking 
part determines whether an alert represents a cause that has already been taken 
into account by the AC algorithm, e.g. is a duplicate alert. Then, a forward- 
looking part determines whether the current alert must be followed by others, 
and in which condition this linkage occurs, e.g. whether consequence alerts have 
to be expected. 



Duplicates. The detection of duplicates relies on the provision of common infor- 
mation by different intrusion-detection sensors, or the provision of mechanisms 
to bridge the different kinds of information. Provision of common information 
means, for example, that two alerts generated by two network-based intrusion- 
detection systems contain an identical quadruple (source address, source port, 
target address, target port) and times that are close to each other. Provision of 
mechanisms to bridge different kinds of information means, for example, that 
there are facts and rules to indicate that two kinds of information are the same 
(for example port number 80 and port name www; two events, one generated 
by a host-based probe as (sourceTiostname, targetiostname, service) and the 
other by a network-based probe (source Jp, source _port, target Jp, target_port), 
will be considered the same if the service can be related to the port target_port, 
and if the addresses and host names match). 

In a configuration file, it has to be specified which alerts are considered 
duplicates. The duplicate definition consists of four associated terms: 
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Initial alert class. The first term is the class of the alert received first. 
Duplicate alert class. The second term is the class of the alert that is under 
evaluation to be a duplicate of the first one. 

List of attributes. The third term is a list of alert attributes. These attributes 
must be equal for the two events to be considered duplicates. 

Severity level. The fourth term is a new severity level for the duplicate alert. 
When a duplicate is found, the AC algorithm uses this severity level for 
further processing instead of the original severity level. 

When an alert is received, the AC algorithm searches for duplicate definitions 
that have as their second term the class of the current alert. It then searches 
the base of previously received alerts for one that matches the class of the first 
term and conforms to the attribute conditions. If this original alert is found, the 
current one is linked to the original one and the severity level of the duplicate 
definition is assigned to the duplicate and used for further processing. 

Note that the duplicate notion implies an ordered sequence. If there is no 
notion of order, then two duplicate definitions should be configured by reversing 
the order of the classes. 

Also, the severity level is a value that can be both positive (the situation is 
more dangerous if the alerts happen one after another) or negative (the situation 
is less dangerous). A specific processing has been applied to the null value. When 
the severity level is 0, the duplicate is simply ignored. 

Actually, the AC algorithm does more in this case: if the duplicate definition 
triggers more than V times (i.e. the counter on the original event reaches a given 
threshold), then a new signature is generated (Event of class X repeated Y 
times) and the contribution of the original event severity times V is added 
to the severity of the situation. This mechanism has been designed to handle 
alert fioods, such as repeated Ping of Death or Teardrop attacks. Such alerts 
usually arrive in batches of 50 alerts or more. The Y threshold is actually a list 
of thresholds (currently 10, 50, 100, 200 and 500), and such alerts will only be 
processed when the count on the original alert reaches one of these values. 



Consequences. A consequence chain is a set of alerts linked in a given order, 
where the link must occur within a given time interval. If the link does not 
occur, an internal alert is generated with the severity given by the consequence 
definition. 

As it holds for the duplicates, consequences have to be defined in a configu- 
ration file. The consequence definition consists of six associated terms: 

Initial alert class. The first term is the class of the original alert. 

Initial probe token. The second term indicates the probe from which the alert 
comes. This can be a variable (in which case it should be the same variable 
as in the fourth term, to indicate that the only constraint is that the two 
probes are one and the same) or a wildcard. 

Consequence alert class. The third term is the class of the alert considered 
a consequence of the first one. 
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Consequence probe token. The fourth term indicates the probe from which 
the alert comes. This can be a variable (in which case it should be the same 
variable as in the second term, to indicate that the only constraint is that 
the two probes are one and the same) or a wildcard. 

Severity level. The fifth term is a severity level for the signature simulating 
the missed alert. 

Wait period. The sixth term indicates the time to wait for the consequence 
alert. 

When an event occurs, the consequence mechanism is triggered. As part 
of this process, the consequence mechanism verifies that the current alert is a 
consequence of some previously received alert. If this is the case, the consequence 
link is marked as having taken place. When the consequence timer expires on 
the original event and all consequences have been satisfied, the processing of the 
original event is terminated. 

The consequence mechanism requires the events to occur in a fixed sequence. 
If the relationship is true regardless of the order, then two consequence defini- 
tions should be used. The consequence mechanism does not provide a way to 
indicate that a consequence occurred after the fixed time limit. Once the timer 
has expired, all linkage is removed. 



Example of Duplicates and Consequences. Let us look at the example of 
a network-based probe able to detect attacks against Web servers in the network 
packets and the Web IDS P probe that looks for signs of attacks in the Web 
server log files. When the network-based probe recognizes a malicious CGI script 
request, it does not know whether the request actually succeeded because it only 
analyzes the request to the Web server but not the corresponding answer from 
the Web server. Since alerts that are related to suspicious CGI scripts occur 
quite frequently, the confidence and severity of this type of alert are low. Web 
IDS on the other hand knows whether the attack succeeded because the Web 
server log entry shows the status code in addition to the URL. 

When the Web IDS alert is received, it is used to upgrade the base event 
and redo the analysis in that light, to lower the severity if the request was 
unsuccessful, or to increase it if the request was successful. 

An example of what the AC algorithm achieves with the detection of du- 
plicates is shown in Figure P which presents an extract of log messages caused 
by two PHF attacks against our Web server. The first PHF attack retrieves the 
/etc/group file, and the second one retrieves the /etc/passwd file. Both attacks 
are successful in the sense that the Web server returned status code 200 (but 
there is no way to tell whether the requested file was actually shipped). 

Web IDS is quicker to report the two attacks, so the Web IDS messages are 
packed together first, and then the RealSecure messages arrive. The first three 
Web IDS messages indicate that the PHF script has been requested, that a 
script has been found, and that a warning should be generated as a consequence 
of these two actions. For the same URL, RealSecure gives only the first warning, 
the PHF request. Analysis is similar for the additional four Web IDS messages 
and two RealSecure messages concerning the PHF request for /etc/passwd. If 
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WeblDS: 934190025 pattern(cgi) phf 10.10.10.62 

"GET /cgi-bin/phf?/etc/group HTTP/1.0" 200 442 
WeblDS: 934190025 pattern (UrlSuccess) *2 10.10.10.62 

"GET /cgi-bin/phf?/etc/group HTTP/1.0" 200 442 
WeblDS: 934190025 decisionCf ollowup) warnings 10.10.10.62 
"GET /cgi-bin/phf?/etc/group HTTP/1.0" 200 442 
WeblDS: 934190027 pattern(suspiciousCgi) passwd 10.10.10.62 
"GET /cgi-bin/phf?/etc/passwd HTTP/1.0" 200 444 
WeblDS: 934190027 pattern(cgi) phf 10.10.10.62 

"GET /cgi-bin/phf?/etc/passwd HTTP/1.0" 200 444 
WeblDS: 934190027 pattern (UrlSuccess) *2 10.10.10.62 

"GET /cgi-bin/phf?/etc/passwd HTTP/1.0" 200 444 
WeblDS: 934190027 decisionCf ollowup) warnings 10.10.10.62 
"GET /cgi-bin/phf?/etc/passwd HTTP/1.0" 200 444 
RealSecure: 934190025 1 HTTP\_PHF 10.10.10.62:9285 10.10.10.61:80 
URL="/cgi-bin/phf ?/etc/group" 

RealSecure: 934190027 1 HTTP\_PHF 10.10.10.62:9304 10.10.10.61:80 
URL="/cgi-bin/phf ?/etc/passwd" 

RealSecure: 934190027 1 HTTP\_Unix\_Passwords 10.10.10.62:9304 
10.10.10.61:80 URL="/cgi-bin/phf ?/etc/passwd" 



Fig. 4. Web IDS and RealSecure alerts. 



we analyze in which ways these messages are duplicates, we find that they have 
the same source and destination, the same URL, and the same time stamp. In 
addition, the RealSecure messages have the same port information. We conclude 
that for the same probe it is quite easy to identify duplicate alerts, whereas 
finding duplicates for different probes is more difficult, especially if we cannot 
rely on time accuracy. 

An additional principle to take into account is the localization of the detec- 
tor, and the possibility to trace the path of an attack. In particular, placing 
two network-based sensors on both interfaces of a firewall with network address 
translation (NAT) is certainly interesting but requires much more work to actu- 
ally relate the alerts to the same “logical” packet. 

5.3 The Aggregation Relationship: Situations 

In many cases, isolated events are not considered significant. Therefore, intru- 
sion-detection alerts are aggregated into so-called “situations”. A situation is a 
set of alerts that have certain characteristics in common. 

Each intrusion-detection event contains information that can act as an ag- 
gregation axis. Our current prototype recognizes three aggregation axes, namely 
the source, the target, and the class of the attack. 

The situation definition consists of the following terms: 

Alert class. The first term is the class of the alert or a wildcard. A wildcard 
indicates that the alert class is not used as an aggregation axis. 
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Source token. The second term is the attack source or a wildcard. 

Target token. The third term is the target of the attack or a wildcard. 
Severity level. The fourth term is a threshold. If the aggregated severity of 
the situation alerts exceeds this threshold, an alarm is generated. 

Since wildcards are allowed, different situation types are possible. By sys- 
tematically evaluating all combinations of aggregation axes and leaving out the 
case where a wildcard is given for source, target, and alert class, we end up with 
seven different situations as follows: 

Situation 1. Alerts with the same source, the same target and belonging to the 
same alert class are aggregated in Situation 1. This allows one to detect, for 
example, an attacker who is launching a series of Web server attacks against 
a single Web server. 

Situation 2-1. Alerts with the same source and destination are aggregated. 
This situation is intended to detect, for example, an attacker who runs a 
series of attacks against the various services available on the target machine. 
Situation 2-2. Alerts with the same target and belonging to the same alert 
class are aggregated. This situation can be used to detect a distributed attack 
against a single target. 

Situation 2-3. Alerts with the same source and belonging to the same alert 
class are aggregated. This situation allows one, for example, to find an at- 
tacker who is running a series of name server attacks against a set of name 
servers. 

Situation 3-1. Alerts with the same source are aggregated. The goal is to de- 
tect a single attacker who runs various attacks against different targets. 
Situation 3-2. Alerts with the same target are aggregated. This allows one to 
detect distributed attacks. 

Situation 3-3. Alerts belonging to the same attack class are aggregated. This 
situation is triggered if, for example, a large number of people are trying out 
a new attack that was recently posted to a hacker mailing list. 

More specific situation alarms have precedence over less specific situation 
alarms. For example, if we assume that the thresholds for all situations are set 
to the same value and situation 1 is triggered, only an alarm for situation 1 but 
not for situations 2 and 3 is generated. 

For situation 2, a list of the values specified in the wildcard field is maintained. 
We refer to it as an alert property list. For example, for situation 2-1 the alert 
property list is the list of all attacked hosts. In the case of situation 3, two alert 
property lists are maintained. 



Determining Authorized Scans. Our ACC can detect authorized security 
scans. The assumption made is that the authorized scan is always executed from 
the same machine. The operator of the ACC knows the address of the source 
machine and can configure the ACC accordingly. 

When messages related to the preconfigured source address appear, within (or 
without) a specific time interval, they are processed by a specific set of situations 
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based on situation 3-1. However, in addition to accumulating scan data on that 
particular class, a comparison of the signatures of the previous scan in terms of 
hosts touched and signatures tried is performed to see whether target machines 
or signatures have been added to or removed from the test. This helps pinpoint 
scan anomalies and also measures the effectiveness of the probes. 



Changing Situations According to Sets of Events. A trigger can be asso- 
ciated with situations. There are two types of triggers, one for situation reeval- 
uation and one for multi-situation assessment. 

Situation reevaluation addresses the case when the operator considers the 
severity of the combination of several alerts not being appropriately reflected by 
the sum of the severities of the individual alerts. For example, the operator may 
believe that a single unsuccessful login request is a mistake and therefore has a 
low severity. However, if somebody tries to unsuccessfully login to ten default 
accounts, then the severity should be much higher than ten times the severity of 
a single unsuccessful login request. The situation reevaluation operates on the 
lists of aggregated alert properties to verify whether the list matches a given 
criterion. For the moment, two criteria have been identified, the length of the 
list, and the fact that the list contains a given sublist. This works for situations 
2-1, 2-2 and 2-3. For situations 3-1, 3-2 and 3-3, the operator has to indicate 
if the reevaluation applies to one property list only, to both of them jointly, or 
to either one of them. The reevaluation takes the form of a modification of the 
severity value, either by a constant, or by a multiplication factor. 

Multi-situation assessment is mostly of use for situation 1, and consists of 
modifying the severity value if another, related situation exists. For example, if 
a host has probed the primary DNS server and now also probes the secondary 
DNS server, the severity of both situations should be increased. 

6 Usage Example 

We give a simple example to demonstrate what our intrusion-detection console 
looks like and how it is intended to be used. The TEC allows one to define 
different views of the alerts that were sent to or generated by the TEC server. We 
have introduced basically two new views, the IDS Alert view where all intrusion- 
detection related alerts are accessible, and the IDS Alarm view which provides 
an interface to those alerts the operator has to take care of. As a simple example. 
Figure 0 shows part of the events the Web IDS probe has generated as a result 
of a detected Web-scan attack. 

In the IDS Alert window shown on the left, all the different CGI attacks 
that were executed show up. In the IDS Alarm window on the right, only one 
message pops up, a situation 1 alarm that summarizes all the individual Web 
attacks. 

The idea is that the operator has only to look at the messages in the IDS 
Alarm window. All the security-relevant alarms are displayed in a condensed 
manner in this window. However, access to single alert messages is still possible 
via the IDS Alert view. 
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Fig. 5. IDS Alert and IDS Alarm views 



7 Conclusions and Future Work 

In this paper, we have shown the need for an aggregation and correlation com- 
ponent (ACC) that can handle alerts generated by intrusion-detection probes. 
We have discussed the requirements such an ACC has to fulfill and have derived 
a system architecture to gather and process alerts in a central place. 

The ACC comprises two main parts: a unified data model for intrusion- 
detection alerts and a set of rules to process the alerts. The AC algorithm can 
detect duplicates, i.e., alerts that are reported by different probes but are related 
to the same attack, as well as consequences, i.e., alerts that are related and should 
occur together. We have introduced the concept of situations that allows us to 
aggregate similar alerts and thus provide the operator with a more condensed 
view of the security issues to be addressed. Alerts are aggregated into situations 
based on any combination of the three attributes source, target and alert class. 

Our ACC is built on the Tivoli Enterprise Console. The integration into an 
existing event management framework had the advantage that we could con- 
centrate on the correlation aspects of our work. Furthermore, the operator is 
provided with a familiar user interface. 

As for future work, we plan to enhance the generic rules of the AC algorithm 
with more specific ones. To improve performance, we will investigate the possi- 
bilities of doing the normalization of alerts as a front-end to the TEC. Currently, 
the ACC does not control the probes but only processes the alerts they generate. 
Therefore, a further enhancement will be to better integrate probes and ACCs. 

Our framework will benefit from having a wide variety of probes integrated 
with it. Hence, we would like to collaborate with partners who are interested in 
seeing their probes being integrated in our framework. 
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Abstract. Host- based Intrusion Detection Systems (IDS) that rely 
on audit data exhibit a delay between attack execution and attack 
detection. A knowledgeable attacker can use this delay to disable the 
IDS, often by executing an attack that increases privilege. To prevent 
this we have begun to develop a system to detect these attacks before 
they are executed. The system separates incoming data into several 
categories, each of which is summarized using feature statistics that 
are combined to estimate the posterior probability that the data 
contains attack code. Our work to date has focused on detecting attacks 
embedded in shell code and C source code. We have evaluated this 
system by constructing large databases of normal and attack software 
written by many people, selecting features and training classifiers, then 
testing the system on a disjoint corpus of normal and attack code. 
Results show that such attack code can be detected accurately. 

Keywords: Intrusion Detection, Malicious Code, Machine Learning. 



1 Introduction 

Some computer attacks require more steps and more time to execute than other 
computer attacks. Denial-of-service attacks that flood a network, or attacks that 
probe for machines or services issue many packets and often continue for hours or 
weeks. This wealth of data and broad time window allows fast intrusion detection 
systems to alert before the attack is over. In contrast, privilege-increasing attacks 
frequently require only a few steps to complete. These attacks can be classified 
into two categories: those that provide access to an unauthorized user, or those 
that provide privileged user access to a normal user. 

Attacks that increase privilege are often launched from the victim, allowing 
the attacker to exploit his access to the system, but also allowing a defender 
to control and limit what comes onto the system. To accomplish an attack, 
an intruder must download or develop code, compile it, and use the compiled 
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tract F19628-00-C-0002. Opinions, interpretations, conclusions, and recommendati- 
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attack. Not all steps need to be performed on the victim machine: sometimes an 
attacker will compile an attack on another, similar machine, and download the 
executable. Sometimes an attacker will use source code to ensure that the attack 
can be compiled and run on the victim. We have performed an experiment that 
verifies that attack code, developed either in C or in shell, can be accurately 
detected and differentiated from normal source code in a manner that does not 
merely detect specific attacks, but rather detects the underlying mechanisms 
required for an attack to succeed. We believe that this approach can be extended 
to detect binary code that grants a user increased privilege. 

This work is closely connected with several branches of security research. 
Intrusion detection systems have been proposed and built that rely on machine 
learning techniques in general and neural networks in particular ITEO . Intru- 
sion detection research is focused on detecting attacks after they have occurred, 
but virus detection scanners detect attacks (usually against Windows or Macin- 
tosh systems) before they are run, so our work has much in common with the 
virus detection literature. In both intrusion detection and virus detection, the 
most common algorithm is known as signature verification, in which invariant 
signatures are scanned for that are known to be representative of attacks HS|. 
In some branches of virus detection and intrusion detection research, systems 
are now being developed with heuristics that describe the steps that malicious 
software might take to infect a system, in order to detect new attacks |fl7l8| . To 
our knowledge, our work is unique in attempting to detect unexecuted code of 
UNIX attacks that increase privilege. 

The system architecture is depicted in Fig. Q The incoming stream, perhaps 
captured from a wrapper around the write system call, is first classified into 
language type: C, shell, or other. If the language classifier fails to recognize the 
sample, then the sample permits the write to complete. If the sample is recog- 
nized and an appropriate attack detector exists, then the sample is processed 
by the language-specific attack detector. Separate detectors can be added to 
increase the coverage of the system. Each detector includes two serial subsys- 
tems, a feature extractor which passes a vector of normalized feature statistics 
to a neural network classifier and (when an attack is detected) additional in- 
formation to the IDS. In this system, if an attack is detected, then the write is 
blocked and the IDS notified. If no attack is detected, the write is allowed to 
complete. To date our research has focused on building accurate language and 
attack classifiers. 

Last year we presented preliminary results of detecting privilege-increasing 
attacks in C and shell source code |p. Those results showed the promise of this 
approach. This year we have validated our approach by expanding our training 
and test sets to include a broader range of normal code, and to include nearly 
ten times more attack code. Furthermore, our test set includes attacks that 
were developed after the attacks used in the training set, to assess how well 
the system might detect new attacks. After careful study of the larger training 
set, we improved the list of features and adopted a new method for normalizing 
a feature statistic that is used as input to a classifier. These changes reduced 
the false positive rate of our system by a factor of two, while also reducing the 
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Fig. 1. System overview. The arrow-line thickness indicates relative volume of data 
flow. 



miss rate by a factor of six. Once the accuracy was improved, we built a fast, 
integrated system to assess the speed that samples could be categorized. 

The remainder of the paper is organized as follows: first, we describe the 
data used to develop our system, select the best features, and train and test the 
resulting system. Next we describe the performance of the components of our 
system, starting with our language classification component, then describing the 
C and shell detector portions. Finally, we describe the overall performance of our 
system when embedded in a file scanner, and discuss how to defeat the system. 



2 Data Sources and Use 

Our technique relies on copious amounts of data to build a system that can ac- 
curately detect a few examples of attack software in a large collection of normal 
software. To date, corpora used to evaluate intrusion detection systems have 
not included the attack software |t)l ID) . Furthermore, databases used for virus 
detection software development have primarily focused on collected examples 
of Microsoft Windows and NT viruses m, while we are interested in UNIX 
attack software. To remedy this, we have gathered normal and attack software 
from a wide range of open-source projects and hacker web sites. The selected 
software was written by different people with different coding styles from differ- 
ent countries. These data were collected into a corpus, including both normal 
and attack software, that is used to train or test each detector. Each individual 
file has been classified by an analyst. 

For system development, we subdivided our first set of data into 10 nearly 
equal groups or folds, then used all folds but one for training and used the 
remaining fold for evaluating, cycling through all examples. For testing, we used 
a disjoint set of files collected after system design was complete. The training 
results in figures are from this 10-fold cross-validation process. The test results 
are from the disjoint data set. 
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2.1 C Corpus 

The normal corpus is composed of files that perform a wide range of different 
tasks, including some operations that an attacker might perform. The software 
packages range from small, single-file programs to large multi-library applica- 
tions. 

The normal C training data includes 5,271 files. Included is a web server 
(apache_1.3.12), which can spawn daemons and interact with network connec- 
tions. Included is a command shell (bash-2.04), which can create and control 
processes, and small programs that work with the file system (fileutils-4.0), or 
that aid with process management (sh-utils-2.0). We included a mail-handling 
program (sendmail-8.10.0) which file system and network capabilities. We in- 
cluded some developer tools for manipulating binaries (binutils-2.10), and com- 
pilers (flex-2.5.4), and an application for debugging programs (gdb-4.18) that 
will manipulate processes. We included software that provides an integrated 
user environment (emacs-20.6) and a library that includes machine-specific code 
(glibc-2.1.3). 

The normal C test corpus has 3,323 files, that were acquired after develop- 
ment of the classifier. Included is an operating system kernel (linux-2.4.0-testl), 
containing machine-specific code that controls a host and manages its connection 
to the network. Also, included is a tool that controls a CD (eject-2.0.2), a tool 
that monitors system usage (top-3.4), and network usage (ntop v. 0.3.1), and a 
large tool that encrypts peer-to-peer communications (ssh-2.4.0). 

The attack C corpus is composed of files downloaded from various repositories 
on the World Wide Web. After reviewing and testing some attack software, 
we noticed that the same attack file will appear in multiple places in slightly 
modified form, e.g., the software will be identical, but the comment sections and 
white space will be different. Further examination and testing revealed that not 
all the attacks found in the various repositories worked. In many cases, the files 
were trivially broken, and the alteration of a few obvious characters would make 
the attack compile and function. Sometimes the problems were more profound. 

To create a corpus of nearly equally weighted examples of attacks, a test 
of uniqueness is used: compare samples by stripping extraneous white-space 
and comments (the residue) against the residue of all samples in the corpus. If 
the residue is unique the original file is inserted into the corpus. This technique 
won’t prevent samples with inconsequential modifications from being added, but 
it limits the number of exact duplications. Uniqueness is required for all corpora. 

We use attack software that is most likely to succeed; if multiple versions 
were available (as happens when some crippled examples are fixed by others), 
we include only the “fixed” version. We did not fix any broken attacks, as that 
would introduce a consistent style to an otherwise diverse range of coding styles. 

The attack corpus is separated into training and testing sets. The attack 
training data is composed of 469 files and is derived from all unduplicated attacks 
available from several web sites scattered around the world 1121131141151 ■ as well 
as all BugTraq exploits between 1 January 2000 and 15 October 2000. The attack 
test data is composed of 67 files collected from nan], and all BugTraq exploits 
posted from 16 October 2000 to 31 December 2000. Both sets of files include 
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attacks against a variety of UNIX-based systems, including Linux, HPUX, Solaris 
and the BSD operating systems. The samples include comment and variable 
words from European languages other than English. 

2.2 Shell Corpus 

Shell training data included 476 examples of normal shell software, harvested 
from SHELLdorado EH, RedHat 6.1 boot scripts, (the contents of the directories 
init.d and rc*.d), and training scripts for Borne, Bash and Korn shells jTTn 
Eom. The attack corpus includes 119 files and comes from BugTraq exploits 
posted between 1 January 2000 and 15 October 2000, the same web sites as the 
C corpus Il2ll8ll4ll(il22l . and some miscellaneous attacks from the World Wide 
Web from 1996 onward. 

The shell test data includes 650 files from RedHat 7.1. The directory tree was 
scanned for all files containing “# ! ” and a valid shell in the first line, and each 
file was verified to be unique. The attack corpus consists of 33 privilege gaining 
attacks mined from the same web sites as the C corpus, as well as BugTraq 
between 16 October and 31 December 2000. 

2.3 Miscellaneous Other Files 

In addition to the corpora described above, 545 files that were neither C code 
nor shell code were used to test how well the system responded to unexpected 
file types. We included several varieties of archived and compressed files. To 
construct the archives, we TAR-ed, GNU gzip-ed, bzip-ed, compress-ed, and zip- 
ed each of the normal C test corpus applications. We also included documents 
with embedded formatting information. We used all of the man pages that came 
with the files in the C test data. We used html, postscript, and pdf versions of a 
book 123!, and included UNIX mbox files from the cygwin mail archive through 
15 February 2001. Finally, we included some plain text files m- 

3 Integrated System Overview 

Although each language-specific attack classifier could be used to examine all 
files, we choose to minimize computational overhead by first identifying the lan- 
guage type of the incoming data. (See Fig.P) Such a choice may cause the system 
to miss attacks, but it is unlikely to increase the number of false alarms. Once 
the language class is determined, an attack detector specific to that language is 
employed to extract features and categorize the source into normal or malicious 
classes. If an attack is detected, the resident IDS is notified and additional data 
gleaned during feature extraction is shared with the IDS, so that a user can 
interpret that attacker’s actions and intended target. 



3.1 Language Identifier 

A fast system with accurate labeling was achieved using a rule-based system 
that exploits the defined structure and syntax of the examined languages. 
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The essence of the rules are as follows. The sample is classified as C upon 
detecting a C preprocessor directive, a reserved word that is neither English nor 
shell, or a C/C++ comment. The sample is classified as shell if the “#!” or shell 
comment character, “#”, is found, or if a word with a “$” prefix is found. In 
addition, there are some rules that preemptively place samples in class other 
(e.g., a mail header, non- ASCII and non-ISO characters, and an html header). 
Finally, if N or more word characters are examined and no match has been 
made, label as other. 

A consequence of these rules is that makefile. Python, and Perl files are all 
classified as shell scripts. If necessary, we can expand our rule set to classify these 
languages, but in practice we have found that few shell-specific features are non- 
zero, and thus nearly all files will be classified as normal text. Additionally, Java 
and C++, and some forms of Fortran that use the C preprocessor will also fall 
into the C class of code. Again, these files tend to have a feature vector that has 
nearly all zero elements and thus is classified as non-attack C code. 

Table E reflects performance of the language classifier on the test data de- 
scribed above. The C samples are from the test corpus, and the shell samples 
are from the train corpus due to the fact we used the “# ! ” to collect some of the 
shell test corpus. To understand the confusion matrix consider an example: of 
the 3390 actual C files, one item was mislabeled as other, none were mislabeled 
shell, and 3389 were correctly labeled. The total error of the matrix is 0.04%, 
with a strong diagonal. We have verified that the mislabeled file in the confusion 
matrix did not cause the detection elements to false alarm. The mislabeled C 
file is a single line of C code that is included in a larger application. The line 
contained some reserved words, but they were all English. Similarly, the mis- 
labeled shell did not use any non-English shell commands, and was comment 
free. In addition, the system is fast: on a 450 MHz SPARC Ultra 60 language 
identification for a kilobyte of data requires 90 microseconds. 



Table 1. Language identifier confusion matrix for all test data. 



Class 


Other 


C Shell 


Computed 


Other 


545 


0 


0 


545 


C 


1 3389 


0 


3390 


Shell 


1 


0 


594 


595 


Actual 


547 3389 


594 


4530 



3.2 Detection 

Once the language has been determined, a language-specific parser examines the 
text for the presence of features that have proven important to correct classi- 
fication. Feature extraction is performed in two steps. In the first step, text is 
separated into several categories that are then examined for a selected set of 
features. The feature statistics are then classified. 
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The feature extractor gathers statistics about each feature type. A feature 
type represents a particular regular expression that is scanned over a particular 
eode category. Each time the regular expression matches, the feature type statis- 
tic is set by applying one of several different encoding schemes. A feature type 
can be thought of as a set of triples: (regular expression, code category, encoding 
scheme), where the regular expression is applied to a particular code category 
using a given encoding scheme. Most feature types are a single triple, but a few 
rely upon information in several different code categories and so will be a set 
of triples. Initially, the extractor parses the code up into four code categories: 
comments (e.g., /* A comment */), strings (e.g., "A string", code-sans-strings 
(e.g., printf 0 ;), and code (e.g., printf ("A string") ;). The first three code 
categories are mutually exclusive, and the last includes the prior two. 

When a regular expression matches within its appropriate code category, 
the match is recorded using one of several different encoding schemes: once: to 
indicate existence, count: to indicate the total number of times a feature appears, 
normalize: count but apply a divisor that represents the size of the code sample. 

A new detector is built by producing a large set of proposed language-specific 
triples. A forward feature-selection process determines the triples that produced 
the most accurate classifier. (For a general discussion of feature-selection meth- 
ods see |ES].) In this process, all N features are considered individually, with 
the feature that creates the smallest total error being selected. After the opti- 
mal vector of dimension one is chosen, the feature vectors of dimension two are 
explored by taking the prior vector to fix the first slot of the new vector, and 

— 1 choices are examined. Induction gives the best vector for dimension TV, 
ending when the feature space is exhausted. Typically, the error will decrease 
as features are added, then increase once the dimension of the vector exceeds a 
certain size. The feature vector that minimizes the total error is termed best and 
used in the production classifiers. There are many permutations of this method; 
we used the LNKnet package developed in our group The majority of 

feature statistics included in our system use the normalized count rule, which is 
effective because it represents the occurrence density. 



C Detector. In building our C attack detector we considered nineteen feature 
types, each intended to model a particular attack or normal action. First, we 
modeled the inclusion of permutations of the words “exploit” or “vulnerability” , 
and built a regular expression that scanned the comment section for these words. 
Next, we realized that attackers exploit race conditions in privileged code by cre- 
ating and deleting links to other files, so we built a regular expression that scans 
the code-sans-strings section for link and unlink or rmdir. Attackers sometimes 
exploit environment variable interpretation in privileged code, so we developed a 
regular expression for functions that modify environment variables, and scanned 
the code-sans-strings section. Attackers also attempt to get privileged programs 
to execute malicious code, so we developed regular expressions to detect the code 
(embedded executable in either code-sans-strings or strings, or C or shell code 
in strings), and the delivery mechanism (an asm keyword for stack insertion in 
code-sans-strings, or calls to the syslog control functions in code-sans-strings, or 
the strcpy and memcpy family of functions in code-sans-strings, or the ptrace 
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function in code-sans-strings) . We also developed regular expressions for the at- 
tack actions themselves, including calls to chown, setuid, setgid, passwd, shadow, 
system, and the exec family of functions in the code section. Some of these mod- 
eled normal code. Regular expressions were developed for obtaining the local 
hostname and detecting the presence of a main function in code-sans-strings. 
Finally, we scanned for the presence of local include files in the code category. 

The result of feature extraction is a vector of feature statistics that is fed 
into a neural network classifier that will be used to learn the best combination 
of feature elements for distinguishing normal and attack code. 

The classifier is a single hidden layer {N, 2N, 2) feed-forward multi-layer per- 
ceptron (MLP) neural network, where N = 19, the dimension of the feature 
space. Some exploration was performed of the number nodes and number of 
hidden layers; this configuration performed well with relatively fast training and 
testing times. The MLP is trained using 10-fold cross validation. 

Results for two classifier configurations {with- comment, and sans-comment) 
are presented here. The with-comment detector could be used when protecting 
a system against naive attackers, while the sans-comment detector is used to 
detect more experienced attackers and prepare for building attack binary detec- 
tors. After performing feature selection on the files and including the comments, 
the with-comment classifier obtains the best performance using only the fea- 
tures for embedded executable (use of hex or octal code), exploit comment, calls 
to exec, use of a local include file, and the presence of a main function. The 
best performance is achieved for the sans-comment classifier with features that 
represent embedded executable (hex or octal code), calls to the exec family of 
functions, definition of main function, and calls to link and system. 

Recall that the MLP emits posterior probabilities, which implies that the user 
can select a threshold appropriate for the environment in which that system is 
being used. To represent the range of choices, we present the performance in 
terms of false alarm versus miss with the curve drawn on normal probability 
axes. The DET curve [l2iSI2Dj for the described classifiers is drawn in Fig. El 
The DET contains the identical information as the ROC curve, although the 
region of high performance is magnified to differentiate systems that perform 
exceptionally well. 

The training data is displayed along with the testing data to show that 
with the exception of the number of samples, these curves are very similar, 
indicating that the classifier performance has converged. The curves show that 
comments improve detection accuracy, but in the case that we ignore comments, 
the classifier still performs well. 

The classifiers are also robust near the zero false alarm level, which is the 
point of the curve where the fielded system will operate. These curves allow an 
IDS to detect a significant fraction of attacks before they are launched. The 
detector is quite fast operationally, analyzing one kilobyte of data in 666 mi- 
croseconds on average on a 450 MHz SPARC ultra 60. Most of this time is spent 
analyzing C code (77%) and reading files (21%), with the remaining time spent 
in language identification. 
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C Detector Shell Detector 





Fig. 2. DET curves of best feature classifiers. Training results are from 10-fold cross- 
validation. 



Shell Detector. Shell code is partitioned into four categories, as is C code. 
Some shell attack code is similar to the attack C code, so we started with C 
attack actions and modified the regular expressions to model shell syntax. In 
addition, we created features specific to shell code. For example, attackers use 
shell code to add new users to a system or to guess passwords, so a regular 
expression was created that detects accesses to either the password or shadow 
password files. Attackers also inserted malicious code into the environment or 
onto a heap or stack, with the result that sometimes the privileged program will 
fail, causing a core file to be saved. Attackers sometimes hide their presence by 
removing these files and touch-ing other files to hide the fact that they had 
been altered, so regular expressions were developed for these actions. We also 
scanned for altering environment variables, and for creating a shared library 
object. We noticed that attackers sometimes attempt to acquire a privileged 
interactive shell, so we wrote a regular expression for this action. Finally, there 
are attacks that altered local security by modifying .rhosts or /etc/hosts files 
and then exploited that modification by connecting to the local host, there are 
regular expressions to model these. 

From the initial feature space, backward feature selection m determines 
the features that give best performance. Backward selection is used because 
the length of the best list is almost the length of the initial list. For files with 
comments retained, best performance was obtained from 15 features in addition 
to the comment feature: localhost: references to localhost, copy: checks for shell 
trojanization, passwd: use a password file, Zmfc:hard or soft link to a file, presence 
of C source code in strings, root: use root in a command line option, test: use 
of a conditional, core: use of core file, exec: use of command, trusted: use of 
a rhosts file, chown: to increase ownership, touchr: use touch -r (mask file 
manipulation times), set[ug]id: use chmod command to suid or sgid, interactive: 
enter into interactive shell, shared: create a shared object. For shell files with 
comments stripped, 12 features were found to give the best performance: code 
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in strings, localhost, set[ug]id, passwd, root, embedded executable', check for hex 
and octal code embedded in strings, link, chown, copy, exec, touchr, subshell: 
check for invocation of a subshell. 

The classifier is a single hidden layer {N, 2N, 2) feed forward multi-layer 
perceptron (MLP) neural network, where N = 16 or 12, depending on whether it 
is used for detecting software with comments or without comments. The resulting 
DET curves is reported here in Fig. El 

Shell code attacks are more difficult to accurately classify than C attacks, as 
can be seen by comparing the DET curves in Fig.|3 The shell detector analyzes 
a kilobyte of data in 1,071 microseconds on average on a 450 MHz SPARC ultra 
60. Of this, 74% of time is spent in the shell code analyzer, 21% in reading files, 
1% in language identification, and 3% in other actions. The larger total time 
spent in I/O is a property of the fact that shell files are typically smaller than 
C, so more time is spent in stream management overhead. A larger amount of 
time is also spent in shell detection compared with C detection. This reflects the 
more complex regular expressions used in shell detection. 



4 Using the System to Scan for Malicious Files 

To test the system we built a simple file scanning tool. An important feature 
of this tool is the ability to specify the prior probability distribution of attacks. 
The prior estimate is used to set the sensitivity of the respective classifiers so 
that we may minimize the total error [30j . Another feature used to wean out 
unlikely candidates is a settable threshold for maximum file size; no file larger 
than 1MB is passed to the language identifier in this test. 

The test was performed on the MIT Lincoln Laboratory Information Assur- 
ance group’s file server. This is a rugged test; there are many opportunities for 
false alarms. Source code of information assurance systems carries many of the 
same features of attack code. The information assurance file server contained 
4,880,452 files and 137,044,936 KB of data on the day it was scanned. Of these 
files, the language identification detector reported 36,600 C samples, and 72,849 
shell samples, for a total of 109,449 candidates for further processing. The de- 
tector reported 4,836 total attacks of which 3855 are C and 981 are shell. This 
indicates a prior distribution of approximately 10% for the C and 1% for the 
shell. Detailed analysis of the output indicates that 143 (3.0%) are false posi- 
tives, of those 33 are C and 110 are shell. If prior compensation is not performed 
the total false positive rate is 5% (versus 3%), which indicates the value of good 
estimates of the prior distributions. 

The field test analyzed a kilobyte of data in 17 microseconds on a 450 MHz 
SPARC ultra 60. This majority of time (54%) was spent reading files, with 
the remaining time being spent in language identification (16.4%), C detection 
(8.7%), shell detection (14.0%) or other (6.8%). The bulk of the time is spent 
with I/O and language detection because the remainder of the files are neither 
shell nor C. 
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5 Discussion 

The system has been trained to accurately detect attacks against many UNIX 
operating systems, because our method requires many examples and because 
these systems share common code. By focusing on one implementation we may 
be able to further reduce the false alarm rate. 

We have found that the flexibility of shell syntax makes it difficult to detect 
shell-code attacks. Even the identification of shell itself is more difficult than 
identifying C code. A valid shell script can consist of little more than a few 
characters, whereas a C sample has much more structure. This flexibility is 
reflected in the processing time of shell versus C, and also in the lengthy list 
of the ’best’ features for shell. Privilege-increasing C attacks generally issue 
buffer overflows, or exploit race conditions. Shell attacks are generally broader, 
sometimes wrap a C attack, use localhost, or attack system and user trust models 
and environment variable interpretation. 

Although this system does an exceptionally good job of detecting today’s 
attack exploits, it is interesting to consider how an attacker might circumvent 
this system once its existence is more widely known. Since the detectors rely on 
matching feature distributions of a new file to measured feature distributions, 
an attacker can defeat the system by either increasing or decreasing feature 
statistics. Since not all source code needs to be executed, an attacker can increase 
feature statistics by including code that will not be called or is placed inside a 
C preprocessor block that will be removed before compilation. Alternatively, an 
attacker can decrease feature statistics. Since most of our features are measured 
with respect to the total amount of code in a file, an attacker can decrease per- 
feature values by increasing the volume of feature-free code. For the features that 
measure the exact number of occurrences, these too can be reduced, perhaps by 
breaking the feature-rich parts of the code into different subroutines or their own 
separate files. Finally, an attacker can discover a new method for accomplishing 
the same action. 

To respond to these threats, we could further improve our parser, perhaps 
performing static analysis of subroutines, updating our regular expressions, and 
supporting multi-file analysis of software. 

6 Summary 

Attack software can be accurately detected and discriminated from normal soft- 
ware for the cases of C and shell source code. When available, comments provide 
valuable clues to improving the classification accuracy. For C code, one of the 
most useful features is embedded binary code that the attacker is attempting to 
trick a privileged program into executing, either by inserting it onto the stack, 
onto the heap, or into the local environment. For shell code, the best feature 
list is long, however the top performers detect embedded C, or references to 
localhost. 

There are a number of interesting ways to deploy this system. In a network- 
based intrusion detection system, ftp-data, mail, and web transfers can be mon- 
itored for the inclusion of attacks. On an ftp server, incoming data could be 
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scanned for attacks. x On a host, a process could periodically be run to scan 
and score source code stored on the disk, or incoming traffic could be examined. 
For example, the FreeBSD operating system runs daily, weekly, and monthly 
security checks of its file systems. This check could be augmented using our file 
scanning software. Alternatively, wrappers to C libraries could be added or a 
kernel modification could be made to scan a file when a disk write is requested. 

Future work will include deeper parsing to make it harder for an attacker to 
hide from this method. For the C detector, we may parse C preprocessor direc- 
tives when enough information exists, and the parser may be made to analyze 
the static call tree. Later systems may analyze multiple files in aggregate when 
there is a collection of related files. We are also starting work in detecting attacks 
in binary files. 

We have shown that a few simple features can rapidly differentiate current 
C and shell attack source code that increases user privileges from normal source 
code. Simple features such as code with embedded binary, and suspicious words 
embedded in comments result in high detection and low false alarm rates. 
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Abstract. Intrusion/misuse detection is the top information assurance 
priority of both the national interagency INFOSEC Research Council 
and the Office of the Assistant Secretary of Defense. Traditional IDSs are 
effective at detecting known attacks; however, developing truly proactive 
defensive systems remains an open problem. This research investigates 
the feasibility of using evolutionary search techniques, in the context of a 
computer immune system, to detect computer network intrusions, with 
particular emphasis on developing techniques for catching new attacks. 
The system provided very low false-negative and false-positive error rates 
during initial experimentation. 



1 Introduction 

Current signature-based network intrusion detection systems (IDS) are reactive 
in nature [1]. Their operation depends primarily upon the existence of signatures 
created during post-mortem analysis of successful attacks, providing a window 
of vulnerability. The success of this type of system is also dependent upon how 
general the signatures are. As in the virus world, new attacks are often modifi- 
cations of old ones, yet, quite often, the “fingerprint” of the new attack differs 
enough from the old one that existing signatures do not catch it (Z). To com- 
plicate the situation further, sophisticated intruders may use stealth techniques 
to perpetrate “low and slow” attacks designed specifically to evade detection by 
IDSs. 

* The material reported herein is based primarily on the first author’s thesis submitted 
in partiaf fuffiflment of the requirements for the Master of Science degree at the Air 
Force Institute of Technology, Wright-Patterson AFB, OH, March 2001. The views 
expressed in this article are those of the authors and do not reflect the official policy 
or position of the United States Air Force, Department of Defense, or the U.S. 
Government. 
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1.1 What GDIS Is and Is Not 

This research attempts to develop a more proactive network-based IDS based on 
the concept of a computational immune system (CIS). The main objective was 
to provide simple, single-packet, network-based intrusion detection (ID) using 
a CIS. Satisfying this objective involved two major design challenges. The first 
was to define a signature, or antibody structure. The second challenge involved 
defining an imperfect matching function; this function provides a mapping be- 
tween the signature and the non-self space. This mapping is constructed to be 
general in the sense that a given signature should match a variety of non-self 
packets, all related by the characteristics of the signature. 

The intrusion detection problem domain is huge, ranging from network-based 
sniffer systems covering an entire enterprise, to host-based sensors that monitor 
the activities of individual processes on a single computer 0. This research ad- 
dresses a portion of the network-based ID problem domain by automatically gen- 
erating antibodies capable of detecting single packets without using the packet 
payload. We recognize that an enormous body of attacks cannot be detected 
based upon a single packet, especially when the packet payload is not considered 
IP. This line of investigation without packet payload is just the starting point. 
We do not intend to replace existing IDSs, but rather to augment and strengthen 
them through defense-in-depth. Further, while this research has demonstrated 
that it is possible to detect previously unseen attacks, the prototype implemen- 
tations currently lacks the ability to identify or categorize the attacks caught. 
Research in this area is continuing, with the investigation of using a clustering 
algorithm to find patterns in bodies of packets caught by GDIS and associating 
those clusters with known attacks or vulnerabilities. 

Many of the difficulties inherent in building and fielding a system capable of 
defending an enterprise information system are not yet addressed in the two cur- 
rent prototype implementations of GDIS. Both prototypes were designed with 
the intention of detecting low and slow network attacks. Although this ambitious 
goal was not attained using these prototypes, other AFIT research projects will 
use them as a foundation for further research in detecting low and slow attacks. 
Both prototypes fit into an existing architecture, the Air Force Institute of Tech- 
nology’s Gomputer Defense Immune System (GDIS). GDIS is a multi-agent, hier- 
archical, distributed computational immune system modeled after the biological 
archetypes of the immunological process It was initially created 

to address the computer virus problem, but has been extended to include the 
ID problem domain. Figure Q] depicts the GDIS building blocks; the dark text 
represents those aspects of GDIS addressed by this research. 



1.2 Computational Immune Systems 

The central model in GDIS is a GIS, which is a model of the biological immune 
system. Algorithms based upon a GIS are not exact models of the biological 
immune system; instead, they abstract the ideas of the immune system applicable 
to the problem being solved, and implement them in some computer setting. 
Only concepts required for the particular application are mapped into the GIS, 
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Fig. 1. Depiction of GDIS Foundation Components 



and natural continuous processes must necessarily be digitized to work on a 
digital computer. 

A CIS also uses the concepts of self and non-self. The definitions of self and 
non-self are important to the proper functioning of the CIS, but each particular 
application will have its own method for defining these concepts m- Ideally, the 
training set representing self is designed to represent as nearly as possible the 
“normal” activity that takes place at the location protected by the CIS. In the 
intrusion detection portion of CDIS, self is defined by a training set of IP packets 
that are known to be attack-free. More details about CISs and their applications 
can be found in 1^. 



1.3 Evolutionary Computation 

Evolutionary Computation (EC) encompasses many methods of simulating the 
biological process of evolution using computers. Most EC algorithms use models 
that are population-based, rely upon random variation and selection for explo- 
ration and exploitation, and are based on the mechanics of natural selection and 
genetics-that is to say that their central concept is survival of the fittest. Typ- 
ically, a run of an EC algorithm consists of many cycles, called generations, in 
which populations of individual solutions are manipulated in a stochastic man- 
ner to create new solutions. Each of the solutions is evaluated for fitness in the 
particular problem domain, and then, typically in a probabilistic fashion, those 
solutions with high fitness compared to the overall population are carried for- 
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ward to the next generation. In theory, the population as a whole gets better 
with every generation. mm 

The EC algorithm used in GDIS is a modification of the genetic algorithm 
(GA), first thoroughly described in Goldberg’s 1989 seminal work jn|. GAs are 
characterized by a strong emphasis on the use of a proportional, probabilistic 
selection operator, and the sparing use of mutation as an exploratory operator. 
GDIS uses the GA as the search mechanism during part of the signature creation 
process. 



2 Related Work 



Much previous work exists in developing artificial and computational immune 
systems, and several research thrusts are underway in this area, such as the work 
at University College London H2]. These techniques have shown considerable 
promise in computer virus and intrusion detection. Our work, however, was 
inspired mainly by the work of Forest et al. |4l9imtUIJ and by the work of 
Lamont et al. here at the Air Force Institute of Technology (AFIT) |7I8I1 . 

Forrest, Hofmeyr, and others at the University of New Mexico have done 
extensive work with designing and using CISs. They have built CISs for host- 
based ID and network-based ID. Their host-based IDS defines self as sequences 
of system calls made by privileged programs, hence it detects abnormal, or non- 
self, system calls mg. Their network-based IDS, called LISYS, uses three features 
for defining self: the source IP address, the destination IP address, and the 
TCP port. Only TCP SYN packets, which signal the start of a connection, are 
monitored by this IDS. Connections that occur frequently are considered part of 
self 0. Our research differs from this work in several ways. For instance, GDIS 
uses 28 features, which include the three used by LISYS. Also, GDIS examines 
all TCP, UDP, and ICMP packets, rather than just monitoring the TCP SYN 
packets. 

Previous work at AFIT developed a system called the Computer Virus Im- 
mune System (CVIS), which is a CIS that detects viruses. It was designed to 
manage sets of antibodies as they move through their lifecycles, to include shar- 
ing good antibodies throughout the system, handling issues like costimulation, 
alarms, and reporting, and producing any applicable reactions to attacks [7|. 
The research discussed in this paper modified CVIS by adding the capability of 
network-based intrusion detection. The modifications are discussed in Sect. 0 
CVIS was renamed GDIS when the ability to perform intrusion detection was 
added. 

Other uses of genetic algorithms in ID include the work by Neri and Ludovic 
Me mm- GASSATA, a host-based IDS designed by Ludovic Me, performs 
security audit trail analysis using a genetic algorithm. Neri compared a GA to a 
deterministic system based upon a greedy heuristic in modeling network traffic. 
In both cases GAs were shown to be effective tools in the search for computer 
network intrusions. 
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3 System Design 

This research modified the GDIS lifecycle process and implemented two proto- 
type systems, Warthog and Ferret. The first prototype, nicknamed “Warthog” 
after the U.S. Air Force’s “low and slow” A-10 tank killer, used an Objectivity 
database to store all of the self-packets and the network packets used for testing. 
The second prototype. Ferret, which was designed to be faster and leaner than 
Warthog, is still in development. It replaces the database with an optimized 
memory-resident data structure, corrects several algorithmic inefficiencies, and 
simulates “on-the-wire” testing of network traffic. Preliminary results indicate 
that Ferret performs much faster than does Warthog; however, because Ferret 
is not yet complete, Warthog was used for the testing discussed in Sect. 01 
Both prototypes handle TCP, UDP, and ICMP packets. These protocols were 
chosen because they constitute the majority of the traffic on our network. Some 
number of attack-free TCP, UDP, or ICMP packets are used as the self-data. 
These packets are loaded into the database or memory data structure and used 
in the negative selection process discussed in Sect. lO The testing data consists 
of some number of TCP, UDP, or ICMP packets that may or may not contain 
attacks. Figure 0 shows part of the Warthog’s graphical user interface that is 
used to build and access the packet databases and to scan for attacks. The 
user interface also allows the operator to visualize the search space, but it is 
currently limited to three dimensions at a time. Williams 021 discusses how this 
visualization tool might allow the human operator to become more involved in 
detection, using a process he calls “interactive evolutionary search.” 




Fig. 2. Warthog Graphical User Interface 
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3.1 Packet Features 

As stated in Sect. II . ll designing a signature structure and representation was 
one of the major challenges faced in building this system. Since the problem 
domain is network-based and the basic unit of traffic on a network is the packet, 
the signatures in GDIS are built around the attributes of packets. A literature 
review of network-based IDSs showed a large diversity in the types of features 
used. For example, the LISYS system from the University of New Mexico uses 
three features as discussed in Sect. 0 while the Snort IDS can use more than 
thirty features for detecting attacks |2D!. We chose to use 28 features for TCP 
and 16 features for UDP and ICMP. Tabled shows the features used for each 
protocolQ All packets were represented as a binary string of 320 bits, regardless 
of the protocol. The binary string representation was used to allow for easy 
manipulation by a genetic algorithm in the affinity maturation process, discussed 
in Sect. 13.31 The packet content or payload was not used as a feature, because of 
the additional complexity it would add. Future research is intended to use the 
packet payload as a feature. 



3.2 Antibody Features 

Antibodies are signatures for detecting non-self packets, or antigens. An an- 
tibody consists of two or more of the packet features shown in Table 0 The 
Warthog implementation limited each antibody to between two and seven ran- 
domly chosen features out of all the attributes available for the protocols; these 
limits were defined through system testing and yielded the best performance 
when using the Objectivity database. Ferret does not use the same database, 
so there is no artificial limit on the number of features that can be used by an 
antibody. 

An antibody is created by randomly choosing a protocol, then randomly 
selecting values for some of the attributes for that protocol. The attribute- value 
pairs of an antibody specify a subregion in the hyperspace corresponding to all 
possible packets. If all attributes were defined for a particular antibody, then 
that antibody would specify a point in the space. A typical signature for an IDS 
such as Snort can also be thought of as representing a subregion or point in this 
same space. 

Since a subregion or point in this space may have limited usefulness in terms 
of catching anomalous attacks, each antibody also has, for each non-boolean 
selected attribute, a randomly chosen range around the specified value. With 
these ranges, each antibody represents a 16- or 28-dimensional hypervolume 
in the 16- or 28-dimensional hyperspace for that antibody’s protocol. These 
hypervolumes can contain many possible packets, and are in fact the embodiment 
of the imperfect matching function discussed as the second design challenge in 
Sect. I I . 1 1 

Both Warthog and Ferret create the antibodies by randomly generating val- 
ues for each feature used and then randomly setting a range about each value. 
In the early stages of development, the ranges were symmetrical. Due to the 

^ Note that each dotted-quad in the source and destination IP address is a separate 
feature, though they are each shown in the table as one item. 
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Table 1. Packet Features 



Field Name 


Possible Values 


IP Fields (Common to all Packets) 




Protocol Type 


TCP, UDP, ICMP 


IP Identification Number 


0-65535 


IP Time to live (TTL) 


0-255 


IP Flags 


0-65535 


IP Overall Packet Length 


0-65535 


IP Source Address (A.B.C.D) 


Valid IP address 


IP Destination Address (A.B.C.D) 


Valid IP address 


TCP-Only Fields 




TCP Source Port 


0-65535 


TCP Destination Port 


0-65535 


TCP Sequence Number 


0-4294967295 


TCP Next Sequence Number 


0-4294967295 


TCP Acknowledgement Number 


0-4294967295 


All TCP Flags 


0-255 


Individual TCP Flags 




(PCWR, Echo, Urgent, Ack, Push, Reset, Syn, Fin) 


Boolean 


TCP Packet Size 


0-65535 


UDP-Only Fields 




UDP Source Port 


0-65535 


UDP Destination Port 


0-65535 


UDP Data Length 


0-65535 


ICMP-Only Fields 




ICMP Type 


0-255 


ICMP Code 


0-255 


ICMP Data Length 


0-65535 



stochastic nature of the range and location creation process, some antibodies 
are created with ranges outside legal values for IP packets, such as ranges that 
include negative values. In Warthog, the database lookup ignores illegal values. 
Ferret, the newer prototype, does not create antibodies with ranges outside the 
allowable values. 



3.3 The GDIS Process 

The life cycle of a network intrusion antibody in GDIS is shown in Fig. 0 The 
GDIS life cycle is adapted from the antibody lifecycle defined by Hofmeyr and 
Forrest |2j and Harmer jZj. The GDIS architecture allows for periodic death and 
creation of new antibodies, but these features, shown as dotted lines in Fig. 01 
have not been implemented in either of the two prototype systems. The processes 
that are implemented by Warthog and Ferret are described below. 
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Fig. 3. GDIS Antibody Lifecycle 



Antibody Creation and Negative Selection. The system first randomly 
generates a user-specified number of antibodies. Each antibody is then passed 
through negative selection, meaning the antibody is checked to determine if 
any self-packets lie within its hypervolume. If so, the antibody is discarded and 
another is randomly generated. The negative selection process continues until 
the desired number of antibodies has been created. This process, which can also 
be considered training, ensures that none of the antibodies match self. Creating 
antibodies is a time-consuming task; however, it is done as an off-line task that 
does not affect the actual detection process. 



Affinity Maturation. Since the antibodies are created randomly, their loca- 
tions and range parameters are not likely to be optimal; in this context, op- 
timality means that the antibody is as large as possible without matching any 
self-packets. Thus, the process of affinity maturation can be used to search inten- 
sively around the given locations for better antibodies. Limited experimentation 
with manipulating the location parameters showed little promise, so Warthog 
only performs affinity maturation on the ranges. The goal of affinity maturation 
is to maximize the hypervolume defined by the ranges of the antibody’s features. 
This maximization is an optimization problem, so evolutionary algorithms are 
a good way of solving this problem. While it is possible to expand the antibod- 
ies deterministically, the relationships between the various axes make doing so 
a computationally expensive task. Instead, a genetic algorithm-based search is 
performed on each antibody’s range parameters by constructing a fitness func- 
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tion that rewards growth until the antibody impinges on self-packets. When this 
happens, the fitness function is modified to reward shrinkage until the antibody 
is pulled back away from the self-packets. This process is an optional aspect of 
the antibody life cycle because it is very costly and time-consuming. An alter- 
native is to create more antibodies; in either case, more of the non-self event 
space is covered by antibodies. Ferret does not implement affinity maturation; 
instead, it is designed to produce a greater number of antibodies than Warthog 
could feasibly create. 



Imperfect Matching Function. As in the human immune system, detection 
of an antigen, or bad packet, is accomplished by “binding” the antibody to it 
via some imperfect matching technique. The GDIS imperfect matching technique 
uses ranges rather than specific points, with each antibody defining a hypervol- 
ume as discussed in Sect. E21 Thus, the matching function is imperfect in the 
sense that it matches any packets in that hypervolume, rather than specifically 
matching or not-matching any single point. 

There are many pattern matching, or imperfect matching, functions in the 
literature today. These comparators come in two basic varieties: similarity mea- 
sures that express how alike two objects are, and difference functions that mea- 
sure how unlike two objects are. Informally, objects that are close together in 
the feature space must be similar, while those that are farther apart are dissim- 
ilar m- In the context of a CIS, system-generated patterns (network protocol 
packets in GDIS) are compared with antibodies containing either self or non-self 
patterns and either accepted or rejected based upon the results of that com- 
parison. Since all GDIS antibodies have undergone negative selection, they are 
guaranteed not to contain known self-packets. Thus, any packet that matches 
a GDIS antibody, within the threshold defined by the range parameters in the 
antibody, can be classified as non-self. 

The concept of an imperfect matching function is very interesting at a meta- 
level. The Computer Virus Immune System, the CIS-based virus detection sys- 
tem upon which GDIS was built, used a sliding-window, binary string comparator 
to determine if a given file matched a virus antibody. Harmer and Lamont did an 
extensive literature review of imperfect matching functions in the binary string 
domain, and of the 12 comparison functions considered, chose the Rogers and 
Tanimoto comparator as being the best fit for CIS-based virus detection jYllSj . 
GDIS initially used the same comparator, but moved to the current hypervolume 
based comparator after experimentation showed that it outperformed the binary 
string matching comparison | 22 |. 



Costimulation. Because GDIS defines non-self as anything outside of the self 
training data, the self-space has to be well-defined in order for GDIS to work 
effectively. However, since self is not perfectly defined and drifts over time, the 
system is likely to produce false positives. A process called costimulation is used 
to reduce the number of false positives that are generated. GDIS is intended to 
operate in a distributed fashion, running simultaneously on multiple computers 
monitoring the same network, working together to detect attacks. Costimula- 
tion in GDIS is the process by which antibodies crosscheck incoming packets 
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with other antibodies. An incoming packet is not categorized as an attack un- 
less multiple antibodies detect it; thus, if only one antibody detects a particular 
packet, that packet is discarded and not reported as an attack. Since the stochas- 
tically generated antibodies can use any of the 28 or 16 available features for 
detection, multiple antibodies may detect a packet as non-self even though the 
antibodies are using different features for detection. 

The costimulation process implemented in Warthog is depicted in Fig. 0 Any 
antibody that detects a non-self packet is compared to the antibodies of other 
computers to see if they have also detected that packet as non-self. If so, the 
packet is marked as an attack; if not, the packet is discarded. An enhancement 
to this process was implemented in Ferret, where an antibody is first compared 
to other antibodies in that same computer before being compared to antibodies 
of other computers. This process allows for internal costimulation, meaning that 
an individual computer can costimulate itself if more than one of its antibod- 
ies detects a non-self packet. This enhancement, while promising, has not yet 
been tested extensively. Therefore, costimulation shall refer to the process as 
implemented in Warthog. 




^ ^ ^ ^ ^ - 

\ 



Detected packets undergo system-wide costimulation 



H 

f \ 

System results 

(Lower false positive rate balanced 
against higher false negative rate) 

V ! ! y 



Fig. 4. Costimulation Process 



Though this process may reduce the number of false positives detected, it 
can also increase the number of missed attacks, since all detected packets must 
be costimulated. The tradeoff between false positives and false negatives is an 
important issue. 



4 Experimental Results and Analysis 

The experimental objectives of the tests included determining: 
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— Is the system capable of determining non-self from self? 

— Is the system capable of detecting unknown attacks; i.e., attacks for which 
it has not been trained? 

— How does the number of antibodies affect the false-positive and false-negative 
error rates? 

— Is the GA-based affinity maturation technique effective in increasing the 
generality of the simple network intrusion antibodies? 

— How does the costimulation process affect the false-positive and false- 
negative error rates? 

The tests were conducted in two separate phases using Warthog, since Ferret 
was not completed early enough to allow testing to be conducted for this paper. 
The first phase of testing used small data sets to reduce the time needed to 
run the tests, while the second phase used more realistic amounts of data to 
simulate the real world. However, Warthog’s database does not scale well when 
large numbers of packets are used for self or detection, so the second phase 
of testing was very time-consuming. Ferret appears to scale much better than 
Warthog and thus allows for the use of large datasets in reasonable amounts 
of time, and Ferret provides the ability to perform detection on the wire. For 
these reasons, it will be the vehicle for future development and testing. Details 
of other tests conducted during Warthog development are not discussed in this 
paper, but they are available in I22|. 

Researchers at MIT’s Lincoln Laboratory (LL) have created a corpus of in- 
trusion detection data for the 1999 DARPA IDS Evaluation PI; we were able to 
benefit from this work by using the existing data. The entire ID corpus contains 
both network and host sensor logs, as well as file system dumps and directory 
listings (among other things) for a notional Air Force base. The LL week one 
data was used for the experiments because it is known to be attack- free; using 
this data ensured the self-data had no attacks and provided a basis for injecting 
attacks into the otherwise clean data. In addition, the LL data is easily accessi- 
ble so that others can use the same data. As discussed in Sect. 01 Warthog uses 
only the TCP, UDP, and ICMP protocols. The LL data was filtered to remove 
all other protocols 0 

4.1 Self or Training Datasets 

For the small test, the self-data consisted of the first 10 K packets of the filtered 
Thursday data. For the larger test, the self-data consisted of all 1,308,081 packets 
in the filtered Monday data. No attacks were injected into either of these data 
sets, as they represent self, or normal network traffic. Negative selection and 
affinity maturation were applied to these datasets to construct the antibodies. 
Table H summarizes the types of packets contained in each self dataset. 

4.2 Test Datasets and Attacks 

The test datasets consisted of attack-free LL data with attacks injected. This 
process of injecting known attacks allowed the testers to control what attacks 

^ The open-source program Ethereal, version 0.8.13, was used to perform the filtering 
using the filter “tcp or udp or icmp” . 
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Table 2. Composition of the Self Datasets 





Thursday - 


10 K packets 


Monday 




Packets 


% of Total 


Packets % of Total 


TCP 


9274 


90.6 


1247366 


95.4 


UDP 


944 


9.2 


59679 


4.6 


ICMP 


22 


0.2 


1036 


0.1 


Total 


10240 


100.0 


1308081 


100.0 



were used and allowed for limited analysis of the results after Warthog was run 
on the test datasets. For the small test, the test dataset consisted of the first 
20 K packets of the filtered Thursday data, while the test dataset for the large 
tests consisted of all 1,085,895 packets in the filtered Tuesday data. Both of these 
datasets had the same attacks injected into them. Table 0 shows the types of 
packets contained in each of the test datasets. The inserted attack packets are 
not included in this table, since they are discussed below. 



Table 3. Composition of the Test Datasets, not Including the Added Attacks 





Thursday - 


20 K packets 


Tuesday 




Packets 


% of Total 


Packets % of Total 


TCP 


18891 


92.2 


1069409 


98.5 


UDP 


1533 


7.5 


15661 


1.4 


ICMP 


56 


0.3 


825 


0.1 


Total 


20480 


100.0 


1085895 


100.0 



The attack set used for testing consisted of a set of 2643 packets taken partly 
from the LL attack data sets, and partly generated using the open source secu- 
rity analysis tool Nessus. This attack set is made up of TCP, UDP, and ICMP 
packets, and contains both short attacks and long sets of scan events. The events 
in this attack set are useful for two reasons. The first is simulating a benchmark 
to which CDIS can be compared. Since there really is no benchmark available 
for computer immune system-based network intrusion detection systems that do 
not make use of payload contents. Snort, using only payload independent signa- 
tures, provides something to which CDIS can be compared. The second reason 
that these events are useful is that they are known non-self. 

The attack set was created in a four-step process: 

1. An abbreviated Snort signature file was created from the 8 Jan 01 Snort 
signatures by removing all the signatures that rely upon the packet payload. 
Out of the 1073 rules in the original signature list, 163 (15%) do not rely 
upon packet payload. 

2. The tcpdump file captured outside the firewall on Thursday of the second 
training week from the 1999 Lincoln Labs ID evaluation corpus was replayed 
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into a network containing a Windows 2000 machine running Snort version 
1.6. Snort was using the abbreviated signature set described above. Snort 
was configured to save the packets captured in libpcap (tcpdump) format. 
Nessus 1.0.6 with all the default plugins active was also run against the same 
Snort machine. The Nessus attacks were run from a machine with addresses 
inside the LL range and the destination machine address was also chosen to 
be within the LL range. Again, Snort saved the captured attack packets into 
a libpcap file. 

3. Ethereal version 0.8.13 was used to parse the libpcap files into text files in 
human readable form. These two files were then concatenated to create a 
text file containing 2643 packets captured by Snort without relying upon 
payload content. Since Warthog currently has no way to work with the pay- 
load content these attack packets provide a fair test of its ability to detect 
anomalous packets. 

4. The Warthog user interface (see Fig. EJ was used to invoke a utility to parse 
the text file created in the last step into a format useable by Warthog. 

Of the 2643 attack packets, 2611 were ICMP, 23 were TCP, and 9 were UDP. 
Most of the ICMP packets are either parts of five of the attacks embedded in 
the LL data0 or they are Nessus-crafted packets originating from an attacker 
or originating from an attacked host and traveling back to the attacker. The 
packets created by Nessus were generated to use the same IP addresses as the 
attackers in the LL data. 



4.3 Testing Environment 

The experiments were run on a homogeneous set of six Dell 933Mhz Intel Pen- 
tium III computers, each with 256M of RAM and the Windows 2000 Professional 
Edition operating system. Objectivity 6.0 was the object-oriented database used 
for storing packets in Warthog. Warthog was written in Java and was run using 
Sun’s JDK 1.3 virtual machine. The small test was replicated on 5 computers, 
while the large test was replicated on 6 computers. In both tests, each computer 
was treated as an independent detector, and the results from the separate runs 
were combined into overall system results. 



4.4 Testing Process 

The first test phase followed each step in the lifecycle shown in Fig.|3 The 10 K 
self-packets were used for negative selection and affinity maturation, while the 
20 K test-packets plus the 2,643 attack packets were used for the detection step. 
First, Warthog ran negative selection to generate antibody sets. Sets of 32, 64, 
128, 256, 512, 1024, and 2048 antibodies were created for each test replication. 
These sets of antibodies were used to scan the stored data for attacks, and the 
results of this test were saved. Next, each of these antibody sets underwent 
the affinity maturation process to generalize the antibodies. These generalized 
antibodies were then used in the detection process to check the test packets. 

^ The relevant attacks are labeled portsweep, Neptune, secret, ipsweep, and ftp-write 
in the LL truth tables. The LL website describes all of the data, including the attacks. 
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Finally, the costimulation process was used on the antibodies, with each set of 
antibodies being handled separately. Costimulation was performed on each set 
of antibodies before and after affinity maturation, so that the effects of affinity 
maturation could be analyzed. 

The second test phase also followed the life cycle shown in Fig. El except 
that the optional affinity maturation process was not used because it ran too 
slowly when the number of self-packets was increased to over 1 million. First, the 
negative selection process was run using the 1,308,081 self-packets to generate 
antibody sets. Sets of 32, 64, 128, 256 and 512 antibodies were created for each 
test replication; 1024 and 2048 were not used because of the large amounts of 
time needed to generate antibodies with a large self-dataset. Next, the detection 
process checked the 1,085,895 test-packets plus the 2643 attack packets against 
each of the antibody sets. Finally, the costimulation process was applied. 

4.5 Experimental Results 

The tests confirmed that Warthog addressed the five main objectives as described 
at the beginning of Sect. El The GDIS system can discriminate self from non-self, 
and it is capable of detecting some unknown attacks. The tests showed that the 
number of antibodies affects the false-positive and false-negative error rates; our 
preliminary results indicate that 512 antibodies provide good detection with a 
low false-negative rate. Testing also showed that affinity maturation was useful 
only when the number of antibodies were low. The costimulation process proved 
capable of lowering the false-positive error rates with little impact on the false- 
negative rate. 

The charts below depict the performance of Warthog. In the limited domain 
tested - no packet payload, single packets, and using fairly small sets of simulated 
data - the system worked very well. The false-negative error rate approached 
zero as the number of antibodies increased above 256, and the false positive rate, 
while climbing as the number of antibodies increased, was still very low in all 
tested cases. The application of costimulation reduced the false-positive rate to 
even lower levels, while not significantly affecting the false-negative error rate. 
The very limited number of test runs does not allow strong conclusions to be 
drawn, but the CIS concepts do show promise. 

Figure El shows the overall system performance on the Phase 1 tests, with 
five replications of the test. The results indicate that increasing the number of 
antibodies over 512 does not significantly improve the false-negative error rate, 
but does raise the false-positive error rate significantly. It was initially thought 
that affinity maturation would be necessary to keep the false-negative error rate 
low, because the affinity maturation process increases the amount of non-self 
event space covered by antibodies. However, the results show that the stochas- 
tically created antibodies perform quite well (against the LL corpus) without 
the computationally expensive affinity maturation operation. It is possible that 
larger amounts of data, or real-world data may require affinity maturation in 
order to be effective. 

Figure El shows Warthog’s performance on the second phase of testing. This 
experiment was run to get a sense for how Warthog performed on more realistic 
amounts of data. The results show that the larger set of self-data dramatically 
decreased both the false-positive and false-negative error rates. The systems 
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Fig. 5. Test Results for First Test Phase, with Small Datasets 



caught every attack in all of the experiments, providing a zero false-negative 
error rate. The false-positive error rate was not zero, but it was quite low. For 
example, the worst performing experiment used 512 antibodies and incorrectly 
classified 72 out of the 1,088,538 test packets as non-self, while the majority of 
the experiments had no false positives at all. While the error rate of 0.00006 
seems very low to us, an analyst tasked with verifying 72 packets every day may 
not be so magnanimous. While we are very pleased with this performance, we 
do recognize that the search space we tested in may not accurately reflect an 
actual network, the attacks we tested against were very constrained, and that 
much more testing will be needed before conclusive results can be drawn. 



Phase Two Test 

False Positives (No Affinity Maturation Tested) 



Number of Antibodies 




Phase Two Test 

False Negatives (No Affinity Maturation Tested) 



0.001 

0.0008 

1 0.0006 

2 0.0004 
0.0002 



— False Negatives Before CoslimiJation 

— False Negatives After Costimulation 



Number of Antibodies 



Fig. 6. Test Results for Second Test Phase, with Large Datasets 
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5 Summary 

The goal of this research was to develop a more proactive network-based IDS 
based on the concept of a computational immune system (CIS), and to provide 
a foundation up which future research can be launched. The main objective was 
to develop a single-packet, network-based IDS using a CIS. 

Overall, this research effort has validated the conjecture that concepts taken 
from immunology can play an effective role in intrusion detection. By leveraging 
the power of evolutionary search, and the model provided by the human immune 
system, an effective, proactive system was developed that has demonstrated a 
capability to detect computer network attacks for which it had not been trained. 
The test results demonstrate that the basic concepts behind CDIS are sound, 
though much work remains before the Warthog or Ferret implementations can 
provide enterprise-level security. 
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Abstract. The Cooperative Intrusion Traceback and Response Archi- 
tecture (CITRA) and the Intruder Detection and Isolation Protocol 
(IDIP) PI provide an infrastructure that enables intrusion detection sys- 
tems, firewalls, routers, and other components to cooperatively trace and 
block network intrusions as close to their sources as possible. We present 
the results of recent testbed experiments using CITRA and IDIP to 
defend streaming multimedia sessions against the Stacheldraht DDoS 
toolkit. Experimental data suggests that these technologies represent a 
promising approach for autonomic DDoS defense. 



1 Introduction 

Distributed Denial of Service (DDoS) attacks are a critical threat to the Internet. 
Increasingly powerful DDoS toolkits are readily available to potential attackers 
and essential systems are ill prepared to defend themselves. For example, in 
January 2001, Microsoft’s web sites hosting Hotmail, MSN, Expedia, and other 
major services were largely inaccessible for 22 hours because of a DDoS attack. 
The security community has long known that DDoS attacks are possible, but 
only recently have such attacks become so easy to launch and popular with 
hackers. 

Although technological advances for DDoS defense are beginning to emerge 
0331 ), the current state of practice relies primarily on expert-labor-intensive 
manual procedures by network administrators. These procedures consist primar- 
ily of two activities: 1) “input debugging” 0, in which administrators at a router 
near the DDoS victim use network traffic probes and statistics to identify the 
router’s physical interfaces through which the DDoS flooding traffic enters their 
network; and 2) mitigation of network traffic flow through those interfaces by in- 
serting packet Altering or rate limiting rules into the associated router. Once the 
offending input interfaces are identified, administrators typically contact their 

* This research was supported by DARPA/Rome Laboratory Contracts F30602-98-C- 
0012, F30602-99-C-0181, and F30602-97-C-0309. Distribntion Statement “A”, Ap- 
proved for Pnblic Release - Distribution Unlimited. 
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counterparts at upstream organizations from which offending traffic is being 
forwarded (e.g., an Internet service provider - ISP). The upstream organiza- 
tions’ administrative personnel carry out input debugging and traffic mitigation 
procedures on their own routers and contact their upstream counterparts. This 
process continues upstream as far as possible until either 1) the flood sources 
are identified and extinguished, or 2) no further upstream cooperation can be 
obtained. 

These procedures have several crucial drawbacks. 

— They require immediate availability of highly skilled network administrators, 
who are in chronic short supply. 

— They are time consuming, even for network gurus. It may take hours or 
longer to diagnose and shutdown a DDoS attack, allowing downtime and 
associated costs to mount. 

— They do not scale. While it is possible to manually trace and mitigate DDoS 
attacks from a small number of networks on an infrequent basis, these proce- 
dures are impractical for attacks involving hundreds of networks or repetitive 
“whack a mole” attacks in which new flooding sources pop up as current ones 
are stopped. Increasingly sophisticated attacks like these are likely to become 
common as hacker toolkits evolve. 

The Cooperative Intrusion Traceback and Response Architecture (CITRA) 
and the Intruder Detection and Isolation Protocol (IDIP) on which it is based 
provide an infrastructure enabling intrusion detection systems (IDS), firewalls, 
routers, and other components to cooperatively trace and block network intru- 
sions as close to their sources as possible. By automating the manual attack 
traceback and mitigation procedures used today, this infrastructure enables net- 
works to respond to intrusions autonomically, and in so doing, addresses the 
drawbacks cited above. 

CITRA and IDIP were initially developed long before the advent of DDoS 
toolkits but were intended to help protect networks against a broad spectrum 
of attacks. We have recently adapted CITRA and IDIP for DDoS protection 
and subjected them to experimental evaluation in a testbed environment. This 
paper describes the results of tests using these technologies to defend streaming 
multimedia sessions against the Stacheldraht DDoS toolkit [TJ- 

This paper is organized as follows. Section 2 provides background information 
about CITRA and IDIP. Section 3 describes our testbed, test scenario, and 
measurement procedures. Sections 4 and 5 present experimental results and the 
observations we derived from them. Section 6 discusses related work, and Section 
7 provides a summary and conclusion. 

2 Background 

CITRA is based on IDIfQ [ I I2lti| . a protocol for reporting intrusion-related events 
and coordinating attack traceback and automated response actions. As shown 



In PI and earlier reports, “IDIP” is used to refer to both a protocol and an architec- 
ture. However, for terminological clarity, the authors recently introduced the term 
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in Figure 1, CITRA components are organized at two fundamental levels. First, 
CITRA communities are administrative domains controlled by a management 
component called a Discovery Coordinator (DC). Second, CITRA communities 
consist of neighborhoods connected to each other via boundary controllers, i.e., 
routers and firewalls. A CITRA neighborhood is the collection of CITRA-enabled 
devices (neighbors) that are adjacent in the sense that no other CITRA nodes 
are interposed between them. CITRA utilizes the neighborhood structure to 
trace and respond to intrusions; the DC, with human oversight, monitors and 
directs activities throughout the community. We are also developing features to 
support a third level of organization: cooperation among multiple CITRA com- 
munities according to business relationships Features to support multicom- 
munity operation include policy-based restrictions on 1) exchange of traceback 
and blocking services, and 2) release and propagation of sensitive information 
about perceived attack severity, deployed sensors, and internal topology. 




Fig. 1. Attack Traceback and Mitigation across Neighborhoods within a CITRA Com- 
munity 



CITRA-enabled devices collect network audit data used in traceback, illus- 
trated in Figure 1. If a CITRA-enabled detector detects an attack (step 1), 
the detector sends a traceback request to each CITRA neighbor (step 2). Each 
boundary controller and host along the potential path of an attack uses its net- 
work audit trail to determine if the packets associated with the attack passed 
through it. If so, the device sends a traceback request to its neighbors (step 3). 



“CITRA” ^ to refer to the architecture, while retaining the use of “IDIP” to refer 
to the protocol. We continue that usage here. 
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This continues until either the attack is traced back to the source of the attack or 
to the edge of the CITRA system. This technique is immune to address spoofing 
because it relies on empirical (audit) data rather than the contents of IP source 
address fields to determine whether a boundary controller is on the attack path. 

At each CITRA component along the attack path, responses are taken in ac- 
cordance with CITRA policy mechanisms Q. For example, at a CITRA-enabled 
firewall or router, the policy may specify that the service (port) being attacked 
at a host should be blocked for all requests originating from the attacker’s ad- 
dress or network for a specified time. For CITRA-enabled hosts, the policy may 
specify that the offending process should be killed or the offending user’s account 
disabled. The current implementation attempts to use the “narrowest” network 
response that stops the current attack, minimizing the negative impact the re- 
sponse might have on legitimate system users. A key premise underlying CITRA, 
ID IP, and corresponding manual procedures used by network administrators is 
that moving attack mitigation actions upstream increases their effectiveness and 
minimizes the collateral impact on other traffic. 

Autonomous responses by individual components along the attack path are 
temporary, e.g., for two minutes; they stop damage immediately and buy time 
for the DC to formulate a more reasoned response. As detectors and CITRA 
devices respond to traceback requests, each device sends a report to the DC 
describing the responses it has taken. This enables the DC to gain a global 
view of how the attack and autonomic responses moved through the community. 
By combining this view with system topology information, in principle, the DC 
can determine an optimal community response, which it orchestrates by sending 
directives to each relevant CITRA platform in the community. For example, 
the DC can remove redundant responses along the attack path to minimize 
the potential negative impact or increase the duration of a response so that it 
becomes relatively permanent. 

In addition, by collecting intrusion detection and response information at 
the DC, CITRA supports community- wide and cross-community aggregation 
and correlation of attacks. 

CITRA and IDIP are supported by software libraries that facilitate the in- 
tegration of existing components. Over the past several years, a variety of IDSs, 
boundary controllers, host-based responders, and other components have been 
integrated together, including commercial products and research prototypes | 2 | ■ 

3 Experiment: Autonomic Response to DDoS 

Given the emergence of DDoS attacks as a critical risk, the authors sought to 1) 
investigate the capability of a CITRA-enabled network to defend itself against 
DDoS attacks and 2) further explore the premise that these technologies are 
applicable to a wide range of network intrusions. 

Although some DDoS traffic can be easily distinguished from legitimate traf- 
fic, this is not true in the general case. More sophisticated DDoS toolkits generate 
traffic that “blends in” with legitimate traffic and therefore cannot be blocked 
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by router packet filters without simultaneously blocking legitimate traffic. For 
such attacks, traffic rate limiting may be more useful than packet filtering. Rate 
limiting is an approximate mitigation strategy because it allows some DDoS 
traffic through and may inadvertently discard some legitimate traffic0. Never- 
theless, if rate limiting parameters are chosen appropriately, rate limiting can 
often ensure that enough useful bandwidth is available for legitimate traffic to 
allow continuation of critical business activities, albeit at reduced speeds. 

With this in mind, the authors integrated a simple rate limiter function on 
CITRA-enabled Linux routers so that it could be used as an alternative intrusion 
response. The rate limiter utilized token bucket rate limiting services provided 
by the netfilter subsystem included in a recent release of the Linux kernel (2.4.0- 
test2). 



3.1 Objective 

The overall objective of the experiment was to provide evidence to support or 
refute the premise that CITRA and IDIP, as manifested in recent prototypes, 
can defend against DDoS attacks. In particular, the authors sought to determine 
whether CITRA’s autonomic activation and upstream propagation of rate lim- 
iting could provide sufficient protection during a Stacheldraht v4 Pj attack to 
allow resumption of a representative, bandwidth-intensive network application. 
We chose Stacheldraht because it is representative of the DDoS hacker toolkits 
that emerged in early 2000. Stacheldraht can generate ICMP and UDP floods, 
TCP Syn floods, and Smurf attacks. It provides one or more master servers that 
issue commands to multiple distributed agents that serve as flooding sources. 
Master servers can target floods at arbitrary machines and ports. This allowed 
us to configure a DDoS attack that is highly disruptive of streaming media ses- 
sions. 



3.2 Test Application 

We chose streaming audio/ video as our representative application in the form of 
the RealNetworks’ RealSystem© server and RealPlayer© clien10 This applica- 
tion is one of the most widely used streaming media applications on the Internet . 
It provides a number of configuration parameters useful for our experiment in- 
cluding choice of transport protocol (TCP, HTTP, or UDP) and audio/video 
encoding rates; the latter can be selected according to the bandwidth available 
between each client and the server. The RealPlayer client also provides real- 
time read-outs of targeted versus actual bandwidth in the form of line graphs or 
histograms. We used these to monitor the impact of DDoS attacks. 

^ Reliable delivery mechanisms that support legitimate traffic will detect lost packets 
and retransmit them. 

^ RealSystem and RealPlayer are registered trademarks of RealNetworks, Inc. 
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3.3 Experiment Topology and Scenario 

The experiment topology is shown in Figure 2. The 100Mbps hub in the center 
is intended to loosely represent the Internet or the backbone of some other 
large network. It provides connectivity among five other subnets, each of which 
represents a different organization’s network. Each of these is represented by an 
ethernet switch or hub with attached nodes and is connected to the “Internet” via 
a CITRA-enabled Linux router. The network at the bottom center of the figure 
represents a server farm and network operations center. The RealSystem server 
is attached to this network. The server is used as the DDoS attack’s target. This 
configuration models highly-publicized recent DDoS attacks in which internet- 
accessible web servers and their surrounding infrastructure were targeted. Figure 
2 also shows the primary flow of traffic from the server to each client. Not shown 
are control channels that flow in the opposite direction, i.e., from each client 
back to the server. A CITRA-enabled network IDS also resides on this network. 
The detection system is a simple flood threshold detector based on the public 
domain utility iplog. Also connected to this network is the server community’s 
DC. 




Fig. 2. Topology and Streaming Media Sessions 



Three RealPlayer clients have been placed on three different networks so that 
the effects of the DDoS attack and CITRA’s autonomic response at multiple lo- 
cations throughout the experimental topology can be observed and monitored. 
RealPlayer Client 1 resides on the same network as the server and is shown ad- 
jacent to it. RealPlayer Client 2 resides on the network in the lower left corner 




140 



D. Sterne et al. 



of the figure. The RealPlayer Client 3 resides on the network in the upper center 
of the figure, which, unlike Client 2’s network, also includes Stacheldraht hood- 
ing agents. Consequently, Client 3’s path to the server is identical to one of the 
fiooding paths to the server. As test data, we used an 8-minute, 11-second con- 
tinuous motion video showing how Boeing 737-300 aircraft are assembled. This 
audio/video file was encoded at 200.1 Kbps. We configured RealPlayer to use 
the “best quality” playback setting with available bandwidth set to 10 Mbps, 
the maximum allowable value, and 5 seconds of data buffering, the minimum 
effective value. Using RealPlayer readouts, we observed an average data rate of 
316.7 Kbps over the 310 second period during which all of the data was trans- 
mitted to the client. The data rate for a single client varied during this period 
from 184.9 Kbps to 668.5 Kbps, with bursts apparently associated with periodic 
buffer refill requests. We configured RealPlayer/RealMedia to use UDP as the 
transport protocol. 




Fig. 3. Stacheldraht Flooding and Autonomic Rate Limiting 



As shown in Figure 3, Stacheldraht agents reside on the six workstations 
on the top row of the figure; one pair of agents resides on each of the three 
upper networks. The Stacheldraht master controller resides on the network in 
the lower left of the figure. Since the master does not need to communicate with 
its agents during the attack, its location during the experiment is not significant. 
We selected Stacheldraht ’s UDP fiooding attack and chose the RealSystem server 
as the attack victim. This sends UDP packets to the server having IP headers 
that are virtually indistinguishable from the control flow packets sent to the 
server by RealPlayer clients. When a fiooding attack occurs, it causes sufficient 
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congestion to prevent these control packets from reaching the server and data 
packets from reaching the client. This in turn causes the video sessions to freeze 
after previously buffered data has been exhausted. 

Figure 3 also shows the positioning and interaction of the CITRA-enabled 
components that participate in the autonomic response. When the detector near 
the RealSystem server detects the flood, it sends a traceback and mitigation 
request to its CITRA neighbors. Its only neighbor is Linux Router 1, which 
determines that it is on the flood path. Consequently, it activates a simple rate 
limiter that is applied to all subsequent UDP packets addressed to the server. For 
purposes of this experiment, rate limiting parameters were fixed at a maximum 
average rate of four packets per second with a burst rate of 10 packets per 
second. Router 1 then propagates the traceback and mitigation request to each 
of its neighbors, i.e., Linux Routers 2, 3, 4, and 5. Routers 1 through 4 each 
determine that they are on the attack path and activate rate limiting using the 
same parameters. Router 5, however, determines that it is not on the attack 
path and does not activate rate limiting. 



3.4 Metrics and Instrumentation 

Our objective was to measure the extent to which automated response could en- 
able resumption and continuation of RealPlayer sessions during a DDoS attack. 
This was measured subjectively by observing the video displayed at each client, 
and objectively by measuring the number of packets received at each client. To 
obtain this measurement, we ran tcpdump on each client and the server, con- 
figured to capture all traffic between the client and server. We processed the 
tcpdump data with a simple script that counted the number of packets in each 
5 second interval for import into a spreadsheet. 

Beyond this instrumentation, we used a packet capture tool to monitor the 
server’s LAN segment. This enabled us to monitor the progress of the DDoS 
attack and response and ensure that the experiment was working according to 
plan. 

We performed five test runs each of normal RealPlayer use, RealPlayer under 
attack with no response, and RealPlayer under attack with IDIP response. In 
each case, we collected the tcpdump data for later analysis. 

4 Experimental Results and Interpretation 

During normal operation (i.e., no flooding present), RealPlayer clients were able 
to complete video data transmission and display with no visible problems. How- 
ever, when a Stacheldraht attack was initiated, flooding of the networks and 
routers was sufficient to immediately prevent RealPlayer clients from commu- 
nicating with the server, freezing their video images shortly thereafter. With 
autonomic response enabled, the attack had no perceptible effect on clients, 
which continued playback without interruption. Traceback and mitigation re- 
quest messages were able to move upstream against the flood, causing CITRA- 
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enabled routers in the flood path to activate rate limiting, reducing downstream 
flooding and enabling resumption of RealPlayer sessions. 

Figure 4 shows results from four representative experiment runs. The x axis 
represents time in 5 second intervals; the y axis represents the number of packets 
received per second at Client 3. Packet rates were nearly identical for all three 
clients for each run. 

The “Normal” run (Figure 4a) represents the number of packets per second 
captured at Client 3 when no flooding is present. During the initial 30 seconds, 
RealPlayer clients received about 140 packets per second, to All playback buffers. 
This would taper off to about 50 packets per second after the first 30 seconds, 
with occasional bursts of about 140 packets per second, presumably to refill 
buffers. This was consistent with the data rates shown on the client statistic 
displays. For the three clients together, this would result in about 420 packets 
per second initially, with the network load reduced to about 150 packets per 
second. Note that although the video was over 8 minutes long, packets arrive 
at the client for only a little over 5 minutes. This is because the client caches 
the data to ensure smooth operation during short periods of congestion. We 
attempted to disable this feature by setting the cache length to 0 seconds, but 
this showed no noticeable difference from when the value was set to 5 seconds, 
which was the value used in the experiment. 

Figure 4b shows that during the “Flood” run, the packet reception rates for 
clients drop to zero very quickly after the flood starts (approximately 40 seconds 
into the run) and stay at zero for the duration of the run. These measurements 
are consistent with the RealPlayer statistics graphs displayed on the clients. The 
extent of flooding was confirmed by the packet capture tool on the server’s LAN 
segment, which showed data rates on that segment of about 75 Mbps, i.e., at 
least 75% loading of the LAN’s 100 Mbps capacity. We also observed congestion 
indications on the “Internet” hub connecting the five routers. The packet col- 
lision indicator light remained lit continuously, reflecting frequent unsuccessful 
transmission attempts. We suspect that the load on the server LAN segment 
was artificially constrained by throughput limitations of Router 1, a 200 MHz 
Pentium Pro that connected the server LAN to the rest of the network. 

When we ran flood attacks with autonomic responses enabled, we observed 
two different behavior patterns: (1) full recovery (Figure 4c) and (2) degraded 
recovery (Figure 4d). The “Full Recovery” histogram shows a dramatic drop in 
packets received at the client for approximately 10-12 seconds beginning around 
40 seconds into the run, followed by a packet reception pattern similar to normal 
operation. This 10-12 second gap represents the time between the onset of the 
attack and the autonomic activation of rate limiting throughout the network. For 
full recovery, the client received the same number of total packets as during non- 
flood runs and the client displays showed no evidence of an attack, suggesting 
that cached data was sufficient to cover the short, flood-induced outage. 

The “Degraded Recovery” histogram shows a longer transmission reception 
time with lower packet rate and fewer total packets received at the client. The to- 
tal number of video packets received at the client decreased dramatically (about 
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1/2) from the full recovery runs, and the duration of transmission spread out 
over the full video length (i.e., it appeared as if client caching had been dis- 
abled). The RealPlayer client video displays for degraded recovery runs were 
visibly choppier. Table 1 shows the differences in time required for video data 
transmission for the three different cases where the video ran to completion. 



Table 1. Duration of Data Transmission 



Mode 


Seconds to Complete Video 
Data Transmission 


Normal Operation (No Attack) 


310 


Autonomic Response with Full Recovery 


325 


Autonomic Response with Degraded Recovery 


475 



Examination of the RealSystem server’s log showed that the server had de- 
tected congestion and adjusted by reducing video quality thereby lowering its 
demand for bandwidth. Thus, if CITRA’s autonomic response did not take effect 
sufficiently quickly, RealServer would detect congestion and attempt to make its 
own adjustments. 

The speed of the detector (a 366 MHz Pentium II in our case) seemed to be a 
significant contributor to this mode change. When the detector acted quickly, full 
recovery was observed. Because the detector monitors the server’s LAN segment 
in promiscuous mode, it may have become overloaded with monitoring when 
the flood started. We conjectured that a more efficient detection algorithm or a 
faster detector platform would likely produce more consistent results, with full 
recovery occurring on every run. 

In an attempt to validate these results independently, a research group in 
another organization reran the experiment in a different testbed [B|. They used 
the same software configuration, however, the hardware platforms differed in 
their configuration. In each case, higher performance components were used. 
The normal and flood runs produced similar results, however, in each run with 
autonomic response enabled, full recovery was observed, supporting our conjec- 
ture that detector speed significantly affects the recovery of RealPlayer clients. 
With higher speed routers, this testbed was also able to achieve 95% loading of 
the server’s LAN segment. In the rerun, CITRA’s autonomic response became 
effective less than two seconds after the start of the flood, as compared with the 
10-12 seconds observed in our slower testbed, a significant improvement. 

5 Observations 

As indicated by the data above, CITRA-enabled routers in the experimental 
testbed traced and successfully mitigated the Stacheldraht attack much faster 
than possible via manual methods. Even though Stacheldraht agents continued 
to generate flood packets, the video sessions continued unimpeded. 
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These results, while encouraging, are preliminary. They constitute a single 
data point in a large, multidimensional space of experimental variables. For 
example, if more flooding agents were used, creating greater congestion, IDIP 
traceback and mitigation requests would encounter more collisions, delaying the 
requests’ propagation upstream. It is for this reason that the IDIP uses UDP as 
a transport protocol rather than TCP. Using UDP (augmented with acknowl- 
edgements and retransmission) allows a traceback and mitigation request to be 
transmitted via a single IP packet. TCP, however, requires the completion of a 
three-way handshake first. DDoS congestion might cause the handshake to fail re- 
peatedly, adding significant delays to the upstream propagation. ID IP’s timeout 
and retransmit algorithm is derived from the cooperative “back off’ algorithm 
used in TCP. An interesting question for further study is whether ID IP’s ability 
to push traceback requests through DDoS attacks could be further improved by 
using a more aggressive retransmision algorithm. 

Another area for further research concerns the scalability of this technology 
to larger and higher speed networks. The CITRA-enabled Linux routers in our 
testbed perform traceback by creating audit records for network flows on an on- 
going basis and examining them for attack path evidence when presented with a 
traceback request. This technique enables routers to trace intrusions that consist 
of a single IP packet. For edge routers, such flow auditing may be practical, but 
for core routers, it might require maintaining an unacceptable amount of state 
or slowing speed-critical packet forwarding operations. (See Sanchez et al jOj for 
a differing view.) One approach to improving the scalability and speed of flow 
auditing is to enable it selectively, i.e., only for flows currently under suspicion. 
While this might result in missing isolated instances of single-packet attacks, it 
might still be useful for tracing 1) single packet attacks that are repeated on a 
massive scale via hacker scripts, and 2) DDoS floods which, by their very nature, 
continue for a period of time. Alternatively, if traceback is sought only for DDoS 
attacks, auditing individual flows is probably unnecessary. DDoS attacks can be 
traced to neighboring upstream routers simply by sampling input packets for a 
few seconds and identifying the input interface from which flood packets entered 
and the link layer addresses from which they were sent. 

An additional topic for further research is the choice of appropriate rate 
limiting parameters. Ideally, these would be chosen in a way that minimizes 
negative impact on benign traffic while mitigating a flood sufficiently to permit 
resumption of normal or near-normal operation. These parameters should be 
recomputed dynamically as a function of flood and normal traffic rates, topology, 
effect of upstream mitigation, and other factors. Optimizing the effects over a 
significant number of routers and network links while ensuring stability in the 
presence of dynamic local adjustments will probably require the application of 
control theory. 
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6 Related Work 

The research most closely related to ours is recent work at AT&T Center for 
Internet Research at ICSI (ACIRI) called Aggregate-Based Congestion Control 
(ACC) and Pushback pTH] . This work grew out of ACIRI’s development of con- 
gestion control and congestion management techniques for routers. Tradition- 
ally, such techniques are meant to stimulate improved behavior of TCP back 
off mechanisms in conformant (cooperative) end systems. This is accomplished 
by discarding packets en route or sending signals such as Explicit Congestion 
Notifications to end points. In m, ACIRI proposes using similar mechanisms 
including Random Early Detection with Preferential Dropping to limit the band- 
width utilized by non-cooperating flows such as the high volume aggregate flows 
associated with DDoS attacks. Recognizing the limitations of local, self-adjusting 
mechanisms in autonomous routers and the need for explicit coordination across 
routers, m proposes adding an inter-router signaling protocol similar to ID IP. 
This protocol allows a router near a DDoS victim to request that upstream 
routers apply rate limiting to specified excessive flows. Like ID IP, these requests 
propagate upstream as far as possible towards the flooding sources, “pushing 
back” the flood. 

In effect, the research group at ACIRI has arrived at an approach very sim- 
ilar to ours but by an entirely different route. They began with packet discard 
mechanisms for congestion management and recently added an upstream signal- 
ing protocol. We began with an upstream signaling protocol for attack traceback 
and mitigation and recently added packet discard as a form of attack mitigation 
specialized for DDoS. 

Primary differences between ACIRI’s work and ours are as follows: 

— ACIRI’s signaling protocol includes periodic upstream refresh messages to 
request continued suppression of DDoS traffic and downstream status re- 
ports to determine whether suppression should be terminated. In CITRA, 
while the initial response to a DDoS attack is undertaken automatically by 
routers, the initial response is only temporary, e.g., for a few minutes. It 
is the responsibility of the DC in each administrative domain, potentially 
with human administrator oversight, to direct routers within that domain 
to continue the response, optimize il|j and terminate it when no longer ap- 
propriate. 

— Although |I2] mentions that a server victimized by a DDoS attack could 
request initiation of pushback, m, m, and El focus on techniques that 
would allow congested routers to detect and identify DDoS attacks by an- 
alyzing their own packet drop histories. Our approach has been to develop 
a generalized intrusion response infrastructure into which a variety of IDSs 
(including ones specialized for DDoS) could be inserted to detect attacks 
and initiate traceback and mitigation. 

— The results published by ACIRI to date are supported by simulations that 
describe the potential behaviors of pushback under a variety of conditions. 

This functionality has not been implemented. 
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The results presented here are based on empirical data gathered from a spe- 
cific testbed and conditions that include a real DDoS toolkit (Stacheldraht) 
and a widely used Internet application (RealPlayer). 

Arbor Networks ^ offers a managed service based on a technology that is 
purported to monitor router traffic for DDoS-specific anomalies, trace attacks 
through neighboring routers, and recommend packet filtering or rate limiting 
rules to the router administrator to mitigate attacks. Because Arbor regards its 
technology as proprietary, they have published few details. It appears however, 
that the technology is intended for use within individual ISPs and end user 
enterprises and does not attempt to propagate DDoS defense requests across 
administrative domain boundaries. 

Recourse Technologies’ ManHunt 0 is purported to “recognize and respond 
to DOS attacks in real time by automatically tracking the attack through the 
chain of ISPs so that the attack can be cut off at the source.” If an upstream 
ISP uses ManHunt, it will be sent a machine readable trace back request which 
it will propagate further upstream. If the ISP does not use ManHunt, it will be 
sent a human readable advisory. 

A number of techniques have been proposed recently for traceback of DDoS 
attacks including itrace uni, packet marking HHSl, use of IP Security tunnels 
m, and packet flow logging ca- Unlike the work described here, these proposals 
do not provide automated DDoS attack mitigation. 

7 Summary and Conclusion 

DDoS attacks are an increasingly critical threat to the Internet. Yet the current 
state of practice for DDoS defense relies on the instant availability of expert 
administrators and time-consuming manual procedures that cannot scale up. 
CITRA and IDIP were designed as a general infrastructure for traceback and 
autonomic response to network intrusions. We have recently adapted our existing 
CITRA prototype for DDoS by integrating a rate limiting function as an addi- 
tional response option for CITRA-enabled Linux routers. The resulting system 
has been subjected to informal tests in a laboratory testbed. The results, which 
have been replicated in a second testbed by another research organization, show 
that under these conditions, the defense provided by CITRA-enabled compo- 
nents allowed RealPlayer streaming media sessions to continue operation despite 
a network saturation attack launched from the Stacheldraht toolkit. We are cur- 
rently developing mechanisms to enforce policy-based restrictions on exchange of 
traceback and response services across administrative domain boundaries such 
as those that exist between ISPs. Potential future work includes additional effec- 
tiveness testing and analysis and potential improvements in traceback speed and 
scalability, ability to reliably deliver IDIP traffic over DDoS-congested network 
links, and ability to compute optimal rate limiting parameters dynamically. 
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Abstract. The global nature of the information infrastructure presents 
enormous opportunities to organizations. However, global interconnec- 
tion also means global risk and implies the need for global defence. 
A central aspect of global defence is information sharing, and at as 
early a point in the incident cycle as possible. This implies the sharing 
of intrusion detection sensor data. The growing recognition of the 
requirement to respect personal privacy is bearing fruit in the passage of 
personal privacy and data protection legislation, which generally limit 
the ability of organizations to share personal information. Based on the 
broad definitions of personal information found in the legislation, source 
IP addresses, one of the key elements of information used in tracing 
malicious activity, may be considered to be personal information, 
and would therefore fall under the purview of the privacy and data 
protection legislation. There are, however, exemptions for the sharing of 
information that could be extended to permit the sharing of intrusion 
detection information while still meeting the intent of the surveyed 
legislation. 

Keywords: Privacy, data protection, personal data, personal informa- 
tion, trans-border data flow, intrusion detection. 
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1 Introduction 

Governments, military forces and corporations have always depended upon in- 
formation technology of some description - smoke signals in ancient days, tele- 
graphs at the turn of the century, networks today - to conduct their day-to-day 
business. As information technology becomes an essential part of the way orga- 
nizations function, the need for interconnectivity and interoperability increases, 
as does the need for exchange of information. These trends bring with them 



W. Lee, L. Me, and A. Wespi (Eds.): RAID 2001, LNCS 2212, pp. 150-^^3 2001. 
(c) Springer- Verlag Berlin Heidelberg 2001 
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significant opportunities to improve service delivery and to move into new areas 
of endeavour. 

Notwithstanding the tremendous benefits that the advent of this technology 
brings, there is, not surprisingly (and perhaps even inevitably), a concurrent rise 
in the ‘dark side of the force’ in the form of cyber-crime and cyber-terrorism. 
The two most important factors in the rise of cyber-crime and cyber-terrorism 
may well be the falling cost of information processing and the development of 
the Internet. As the cost of information processing falls, more and more govern- 
ments, non-government organizations and individuals will be able to acquire the 
ability to present a potential and credible threat. The Internet permits the rapid 
transfer of information (the hacking community excels at the rapid exchange of 
information), so not only will more players engage in these activities, they will 
continually improve by learning from other’s mistakes. 

Absolute security is not practically achievable - a certain amount of vulner- 
ability, and hence risk, will always be present. The interconnection of various 
national infrastructures to create the Global Information Infrastructure (GII) 
makes it more and more difficult for any one individual, organization or nation 
to control their own security environment - even within national boundaries. 
The problem of Information Protection transcends national boundaries. Without 
appropriate international agreements and cooperation among nations and inter- 
national organizations, the collective ability to handle threats will be severely 
hampered. 

This is the concept of “shared connections, shared risk” , with the implication 
that there is a corresponding requirement to share responsibility for the protec- 
tion of the GII. While eradicating information attacks may not be a realistic 
expectation, the aim should be to make significant progress in defending against 
all forms of attack, enough so that the risks can be kept to acceptable levels. In- 
formation attacks involve non-physical attacks on information, information pro- 
cesses, and information infrastructures that compromise, alter, damage, disrupt, 
or destroy information and/or delay, confuse, deceive, and disrupt information 
processing and decision making. Increasingly, governments are turning to legis- 
lation as one means of combating the rise of cyber-crime and cyber-terrorism. 

2 Aim 

It is not the intent of this paper to argue the merits of a legislated approach to 
combating cyber-crime and cyber-terrorism, nor is it the intent of this paper to 
substitute for considered legal advice. Rather, the intent is to examine the impli- 
cations of recently enacted privacy and data protection legislation on the ability 
of governments and other organizations to share intrusion detection information 
in response to the threat. 

3 Why Is This an Issue? 

Gurrent information technology gives organizations a greater ability to collect 
and access information than ever before. With this ability comes an increased 
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obligation to protect personal information and privacy. Citizens expect reliable 
electronic delivery of programs and services and protection of the privacy of their 
personal information. Failure to meet this expectation (i.e. if a cyber-based inci- 
dent seriously compromises public confidence in government or business ability 
to ensure secure and trusted electronic delivery of its programs to citizens) will 
endanger the prospects of success for the move to e-government and e-business. 

This is a particularly current issue in Canada, where all levels of government 
have indicated their desire to help Canadians realize the full benefits of elec- 
tronic commerce and electronic government. The federal government is itself an 
extensive user of information technology both for its own internal operations and 
the delivery of its services to the public. In the October 12th, 1999 speech from 
the Throne, the federal government reaffirmed the importance of information 
technology to its service delivery vision: 

Governments ean, and should, be at the leading edge of the information 
revolution. A model user of the new technologies to improve services to 
Canadians. By 2004, our goal is to be the most electronically connected 
government in the world to its citizens. So that Canadians can access 
all government information and services on-line at the time and place of 
their choosing^ 

To realize this vision, the government has embarked on the Strategic IM/IT 
Infrastructure (SII) Initiative, which sets out the underpinnings of secure, citizen- 
centered electronic service delivery, aimed at enhancing operations and eliminat- 
ing barriers to more responsive service options 0 The development of the SII is 
based on a number of architectural principles, including security, confidentiality, 
privacy and the protection of information. In fact, the top priority of the SII is 
security and privacy, issues that the digital era and the Internet have brought to 
the fore. The SII is to be implemented in such a way as to conform to govern- 
ment security and privacy policies and laws0 Information within the SII is to 
be protected against unauthorized access, denial of service and both intentional 
and accidental modification, as well as against improper use. In order to ensure 
that the infrastructure is capable of meeting these requirements a security ar- 
chitecture, comprising a variety of technologies, including intrusion detection, is 
being defined and implemented. 

Similarly, the recent creation of the Office of Critical Infrastructure Protec- 
tion and Emergency Preparedness is bringing critical infrastructure protection 

^ The Right Honourable Jean Chretien, Prime Minister of Canada, in his “Response 
to the Speech from the Throne”, October 13, 1999, Ottawa, Ontario. 

^ Strategic Directions for Information Management and Information Technology: En- 
abling 21st Century Service to Canadians, 18 October 1999. 

^ For example, see “Overview of Strategic IM/IT Infrastructure Initiative”, a pre- 
sentation given by Jim Alexander, Program Director SII, Chief Information Officer 
Branch, Treasury Board of Canada Secretariat, dated 24 November 1999. In this 
presentation, it is clearly indicated that Bill C-6 (the Personal Information Protec- 
tion and Electronic Documents Act) is part of the policy framework governing the 
SII. 
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to the fore. The role of this new Office is to develop and implement a compre- 
hensive approach to protecting Canada’s critical infrastructure. It is to provide 
national leadership to help ensure the protection of this infrastructure, in both 
its physical and cyber dimensions regardless of the source of threats and vulnera- 
bilities. The new Office is to build partnerships with the private sector (governed 
by the provisions of the Personal Information protection and Electronic Docu- 
ments Act), the provinces and territories (all of which either have or will have 
privacy legislation), municipalities, and key international partners (which also 
have privacy or data protection legislation). A key aspect of these partnerships 
will be the sharing of threat and vulnerability information^ Therefore, it is es- 
sential to establish what, if any, limitations on information sharing are imposed 
by privacy and data protection legislation. 



4 The Legislation 

For the purposes of this paper, the author has focused on a review of the following 
legislation or regulatory schemes (these are intended as a representative sample 
- this is by no means an exhaustive list): 

a. The European Union (EU) Directive on Data Protection; 

b. The United Kingdom’s Data Protection Act; 

c. Canada’s Privacy Act and Personal Information Protection and Electronic 
Documents Act (Bill C-6); 

d. Australia’s Privacy Act; and 

e. The United States’ Safe Harbor Program. 

These particular schemes were chosen for a number of reasons, including: 

a. These countries or groups of countries represent Canada’s key allies and 
trading partners. For example, the US and EU represent some 91% of all 
exports and 83% of all import^; 

b. There is, to a large degree, a common viewpoint with respect to privacy 
(most of these documents reflect the original OECD Guidelines); and 



Taken from notes on The Office of Critical Infrastrncture Protection and Emergency 
Preparedness, as published to the Emergency Preparedness Canada website. 

® Department of Eoreign Affairs and International Trade (Canada), Economic and 
Trade Analysis Division, “Second Annual Report on Canada’s State of Trade (Trade 
Update 2001)”, dated May 2001, Table 3, page 7 (export figures) and Table 10, page 
20 (import figures). 
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c. These documents are applicable, in varying degrees, to organizations in both 
the public and private sectors, so they cover most or^nizations that might 
be involved in sharing intrusion detection informationQ. 



5 ‘Personal Information’ Defined 

The above-mentioned legislation imposes conditions on public and/or private 
sector organizations regarding the processing of personal information. Central 
to this discussion is whether or not the definitions of “personal information” 
cover any of the data that could potentially be gathered by an intrusion detection 
system (IDS). It is assumed that the content of e-mails and other user-entered 
data would be considered personal and therefore subject to the above legislation. 
It is not immediately clear, however, if the header or control portions of the 
data are similarly governed. It is further assumed that the only information to 
be shared would be information relating to malicious or potentially malicious 
activity. The issue of whether or not an individual or organization involved in 
malicious activity forfeits any rights to privacy is an entirely separate matter 
and will not be discussed in this paper. 

A review of the selected legislation reveals a number of common elements 
in the definitions of ‘personal information’, or ‘personal data’ in the case of the 
European Union Data Protection Directive and the US Safe Harbor program. 
These elements include: 

a. The information must relate to an identified or identifiable natural person 
(also known as the “data subject”); 

b. The identification of the individual may be done directly or indirectly, 
using information that is already in the possession of an organization or 
information that is likely to come into the possession of an organization; 



® For example: (EU) Directive on Data Protection applies to all organizations estab- 
lished on the territory of a Member State, including branch offices and snbsidiaries; 
(UK) Data Protection Act has similar application; (Canada) Privacy Act applies 
to federal government while the Protection of Personal Information and Electronic 
Docnments Act applies to private sector organizations; (Australia) Privacy Act (as 
amended) applies to federal government and selected elements of the private sector 
(e.g. credit reporting); and (US) Safe Harbor applies to elements of the private sector 
not otherwise regulated. 

Processing is defined in the selected legislation as “any operation or set of operations 
which is performed upon personal data, whether or not by automatic means, such as 
collection, recording, organization, storage, adaptation or alteration, retrieval, con- 
sultation, use, disclosure by transmission, dissemination or otherwise making avail- 
able, alignment or combination, blocking, erasure or destruction”. See, for example, 
EU Data Protection Directive, Chapter 1, General Provisions, Article 2, Dehnitions, 
page 11. See also (UK) Data Protection Act 1998 (Chapter 29), Part I (Preliminary), 
Section 1 (Basic Interpretive Provisions). 
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c. The identification of the individual may be made by reference to any 
identifying number, symbol or other particular assigned to the individual, to 
one or more factors specific to his physical, physiological, mental, economic, 
cultural or social identity and includes any expression of opinion about the 
individual; and 

d. The information about the individual may be recorded in any form, including 
as part of a database 0 

The above legislation is based on or consistent with the principles outlined 
in the OECD Guidelines on the Protection of Personal Information0 “Personal 
data” under the OECD Privacy Guidelines includes “any information relating 
to an identified or an identifiable individual (data subject)”, which by direct 
(e.g. a civil registration number) or indirect linkages (e.g. an address) may be 
connected to a particular physical person. Collections of data that do not offer 
such possibilities (e.g. statistical data in anonymous form) are not included FI 
Note that in all of the legislation the ability to uniquely identify an individual 
appears to be the determining factor as to whether or not the information is 
‘personal’. Provision is also made for the use of information that is either already 
in the possession of a person or organization and information that may come 
into their possession. In all cases, the wording of the definitions is such that they 
could be interpreted rather broadly as to what falls under their purview - this 
is certainly the trend in CanadaO 

® (European Union) “Directive 95/46/EC of the European Parliament and of the 
Council of 24 October 1995 on the protection of individuals with regard to the 
processing of personal data and on the free movement of such data” (hereinafter 
EU Data Protection Directive), Chapter 1, General Provisions, Article 2, Defini- 
tions, page 11. See also: (United Kingdom) Data Protection Act 1998 (Chapter 29), 
dated 16 July 1998, Part I (Preliminary), Section 1 (Basic Interpretive Provisions); 
(Canada) The Privacy Act (R.S. 1985, c. P-21 (The Privacy Act)), Interpretation, 
paragraph 3; (Canada) Personal Information Protection and Electronic Documents 
Act 2000, Part 1, Protection of Personal Information in the Private Sector, Inter- 
pretation, paragraph 2; (Australia) Privacy Amendment (Private Sector) Act 2000 
(Act No. 155 of 2000), assented to 21 Dec 2000; (Australia) The Privacy Act 1988 
(Act No. 119 of 1988 as amended). Part II, Interpretation, Section 6, page 10. The 
compilation used was prepared 24 May 2001 incorporating amendments up to Act 
No. 24 of 2001. 

® (OECD) “Guidelines on the Protection of Privacy and Transborder Flows of Per- 
sonal Data” (hereinafter “Guidelines”), dated 23 September 1980. See also: (UK) 
Data Protection Act 1998 (Chapter 29), Schedule 1 (The Data Protection Princi- 
ples), Part I, The Principles; (Canada) Protection of Personal Information and Elec- 
tronic Documents Act 2000, Schedule 1 (Section 5); (Australia) Privacy Act 1988 (as 
amended), Part III, Section 14; and (US) “Safe Harbor Privacy Principles”, dated 
21 July 2000. 

(OECD) “Guidelines”, page 15, para 43. 

For example, see the Supreme Court of Canada in Dagg v. Canada (Minister of 
Finance), [1997] 2 S.C.R. 403, where personal information is information about an 
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None of the surveyed legislation distinguishes between personal information 
contained in the content portion of a packet and that in the header. However, 
EU Directive 97/66/EC, dealing with privacy in the telecommunications sector, 
introduces the concept of traffic data. Traffic data is defined as data processed 
in the course of or for the purpose of the transmission of a communication 
over an electronic network Fn The Annex to the directive lists various types of 
traffic data, including the number or identification of the (calling) subscriber 
station and called subscriber number [3 Although the current wording of Direc- 
tive 97/66/EC would seem to exclude IP addresses, a strong argument could be 
made that source and destination addresses are the Internet analogues of calling 
and called subscriber numbers or identification and would therefore fall within 
the existing definition of traffic dataO 

It is possible to trace Internet communications back to their source (whether 
or not it is practical to do so is another issue). Typically the trace ends at a point- 
of-presence such as an Internet Service Provider (ISP), who generally has the 
information needed to make the final connection, and tie that communication 
to an identifiable individual. All of the elements of personal information are 
present at some point during this activity, which leads the author to conclude 
that information such as source IP addresses constitutes personal information as 
defined in the above legislationO This conclusion also appears to be consistent 
with a number of papers dealing with the protection of privacy in intrusion 
detection systems, where the authors include IP addresses amongst the sensitive 
information that needs to be protectedQ It is important to note, though, that 



identifiable individual that is recorded in any form including addresses, number, 
symbols and/or other particular assigned to an individual. 

Data Protection Working Party, “Opinion 7/2000 On the European Commission 
Proposal for a Directive of the European Parliament and of the Council concern- 
ing the processing of personal data and the protection of privacy in the electronic 
communications sector of 12 July 2000 COM (2000) 385”, dated 2 November 2000, 
page 3. The Data Protection Working Party was established under Article 29 of the 
EU Data Protection Directive. It is the independent EU Advisory Body on Data 
Protection and Privacy. 

“Directive 97/66/EC of the European Parliament and of the Council of 15 December 
1997 concerning the processing of personal data and the protection of privacy in the 
telecommunications sector” (hereinafter Directive 97/66/EC), Annex. 

Data Protection Working Party, “Opinion 7/2000”, page 4. 

This is also consistent with opinions expressed by the Data Protection Working 
Party, Working Document, “Privacy on the Internet - An Integrated EU Approach 
to On-line Data Protection”, dated 21 November 2000, page 21 (IP addresses are 
referred to in terms of ‘personal data’. See also Beardwood, John, “Privacy Issues” 
a paper produced for The First Annual IT Law Spring Training Program, 27 - 29 
April 2000, sponsored by The Law Society of Upper Canada Osgoode Hall, Toronto, 
Canada (“at the point that such information (IP or e-mail addresses) is associated 
with an individual, then the information becomes personal information”). 

Biskup, Joachim and Flegel, Ulrich, “Transaction-Based Pseudonyms in Audit Data 
for Privacy Respecting Intrusion Detection”. In H. Debar, L. Me and F. Wu (Eds.): 
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this is strictly the author’s understanding of how the term ‘personal information’ 
may be interpreted. The author has not been able to find any specific case law 
that concludes that IP addresses actually constitute personal information for the 
purposes of the above legislation^ 

6 The Challenge 

One of the challenges the security community faces is to develop appropriate 
and effective responses to attacks against information and information systems. 
Prompt response to an attack can limit damage and save the rest of the commu- 
nity from a similar fate. Responses to attacks include identification, analysis of 
the method of attack, interdiction, apprehension and punishment and retaliation. 
The ability to implement any of these responses presumes that the responding 
organization has adequate information upon which to base response decisions. 
Intrusion monitoring data is one such source of information. 

Collection, analysis and dissemination of information about attacks are vital 
to maintaining parity with attackers. The adage of “forewarned is forearmed” 
is particularly relevant here. Sharing of suitably sanitized information amongst 
concerned organizations can contribute to the common good and can provide 
access to other sources of information and expertise through the development of 
trust amongst the organizations concerned. Open, effective communications are 
essential to provide the information required at each level to support incident 
response. 

This is not only a technical challenge, but it is also an organizational chal- 
lenge. There are several examples where the sharing of information relating to 
intrusions has been formalized to some extent, including the Forum for Inci- 
dent Response and Support Teams (FIRST) and the United States’ Information 
Sharing and Analysis CentersQ However, the enactment of legislation, which 
seeks to impose limits on the nature and quantity of information that is col- 
lected and shared by various organizations, may act as a brake on these kinds 
of activities. It is clear from the above discussion that intrusion monitoring data 
contains personal information, as defined in the above legislation. The central 
issue, then, is whether or not these acts hinder or facilitate the sharing of this 
information for the purposes of early warning, response and investigation. 

Proceedings of Recent Advances in Intrusion Detection 2000, pages 28 - 48, Springer- 
Verlag Berlin Heidelberg, 2000. See also Lundin, Emilie and Jonsson, Erland, “Pri- 
vacy vs. Intrusion Detection Analysis”, as submitted to the Second International 
Workshop on the Recent Advances in Intrusion Detection, hosted by Purdue Uni- 
versity CERIAS, West Lafayette, Indiana, USA, 7-9 September 1999. 

A search was performed, using the QuickLaw search engine, for any Canadian case 
law relating to the concept of IP addresses as personal information. The search did 
not turn up any relevant case law. 

ISACs have been established for the following critical infrastructures: energy, trans- 
portation, financial services and telecommunications. There has been limited discus- 
sion within Canada concerning the adaptation of the ISAC concept to the Canadian 
context. 
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7 The Technical Response 



There are a number of valid reasons why organizations would want to share 
intrusion detection data/information. These include gaining access to subject 
matter expertise and establishing trends or patterns. Perhaps most importantly, 
due to the highly interconnected nature of information infrastructures, informa- 
tion sharing results in receiving or providing early notification of threats thereby 
reducing, if not avoiding altogether, the expenses or loss of reputation from an 
unexpected attack. There may be regulatory or legislative requirements to dis- 
close this information (e.g. requirement to disclose information related to sus- 
pected criminal activity). Prompt reporting of intrusion detection information 
may also be required in order for corporations to demonstrate due diligence. 

However, there is a need to balance the need to share information for protec- 
tive purposes with the imperative to respect the privacy of the individual. There 
is a growing awareness of the potentially intrusive nature of the technology used 
in the WWW and the Internet and there is growing demand for enforcement of 
privacy rules via technical means (the use of privacy policies notwithstanding). 
Some solutions focus on providing complete anonymity (privacy), while others 
attempt to achieve a balance between the two imperatives of privacy and se- 
curity. For example, the Freedom Network from Zero-Knowledge uses layers of 
encryption and multiple Anonymous Internet Proxies (AIPs) to allow users to 
engage in a variety of pseudonymous activities, hiding the user’s real IP address 
(and other identifying information) from active attempts to violate user privacy. 
Users can create multiple pseudonyms, and these pseudonyms cannot be linked 
together, nor can pseudonyms be traced to a specific userFi 

Alternative pseudonym scheme^3 provide anonymity and protection for per- 
sonal information while providing the capability to (re)discover the personal in- 
formation through the use of some form of database linking pseudonyms and real 
names. In all of the pseudonymization schemes put forward, the pseudonymiza- 
tion takes place before intrusion detection or audit analysis. The introduction of 
privacy and data protection legislation may actually favour the continued devel- 
opment and commercialization of pseudonymous intrusion detection capabilities. 
As well, the requirements to erase or pseudonymize the information when it is no 



Boucher, Phillippe; Shostack, Adam; and Goldberg, Ian; “Freedom System 2.0 Ar- 
chitecture”, Zero- Knowledge Systems, Inc., 18 December 2000. 

Lundin, Emilie and Jonsson, Erland, “Privacy vs. Intrusion Detection Analysis”. See 
also: Sobirey, Michael, Fischer- Hubner, Simone and Rannenberg, Kai, “Pseudony- 
mous Audit for Privacy Enhanced Intrusion Detection”, in Louise Yngstom and Jan 
Carlsen: “Information Security in Research and Business: Proceedings of the IFIP 
TCll 13th International Information Security Conference (SEC ’97)”, 14 - 16 May 
19997, Copenhagen, Denmark; Buschkes, Roland and Kesdogan, Dogan, “Intrusion 
Detection and User Privacy - A Natural Contradiction?”, slides presented at the 
First International Workshop on Recent Advances in Intrusion Detection, Louvain- 
la-Neuve, Belgium, 14 - 16 September 1998; and Biskup, Joachim and Flegel, Ulrich, 
“Transaction-Based Pseudonyms in Audit Data for Privacy Respecting Intrusion De- 
tection” . 
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longer required are compelling reasons to continue development in this area, FI 
Pseudonymization is probably the most promising means of balancing the op- 
posing imperatives of security and privacy, but there is still some way to go 
before such techniques will be viable on a large scale. 

But while they solve one set of problems, anonymization or pseudonymiza- 
tion of the intrusion data creates other problems. In order to determine who is 
responsible for the intrusion, to respond to the intrusion in a meaningful way 
or to assess damage, it is essential to be able to establish a link between events 
and users. Extensive pseudonymization makes advanced analysis difficult and 
time consuming, thus decreasing the effectiveness and efficiency of the intrusion 
detection process FI 

In the event of an intrusion, there is a need for re-identification to be done 
quickly so as to minimize the damage caused by a particular event and to per- 
mit rapid early warning to other organizations. This is in direct contrast to the 
impact of pseudonymization, which is to add several more steps to the intrusion 
detection process, thereby increasing the time necessary to react. As well, the use 
of pseudonymized information does not readily support prosecution. Intrusion 
detection systems are not designed to collect legally acceptable evidenc^, and 
yet the sensor logs may be key to proving that a particular individual was re- 
sponsible for a particular event. There will be an increased burden to prove that 
the pseudonymization process is resistant to tampering, is repeatable and that 
the pseudonyms can be exactly matched to the original identifying information. 

The pseudonymization techniques put forward by these authors appear to 
be directed mainly against accidental or inadvertent disclosure of information. 
Although the use of pseudonymized information may be adequate for periodic, 
statistical reporting, their use does not readily lend itself to prompt, deliberate, 
authorized disclosure (e.g. the sharing of early warning information), particularly 
if source IP addresses are among the information being pseudonymized. It is this 
very specific information that is most essential for responding to an attack (e.g. 
via construction of new router filters or firewall rules). Disclosures of this nature 
would require the re-identification of the source of the event, which as mentioned 
above reduces the speed of response. 

8 Trans-Border Data Flows 

As mentioned earlier in the paper, the collection, analysis and dissemination of 
information about attacks will be essential to maintaining parity with attack- 
ers. This is particularly true with respect to some of the earliest indicators that 

“Directive 97/66/EC”, Article 6(1). See also EU Data Protection Directive, Article 
6(le). 

Lundin, Emilie and Jonsson, Erland, “Privacy vs. Intrusion Detection Analysis”, 
page 8. 

Sommer, Peter, “Intrusion Detection Systems as Evidence”, as presented at the 
First International Workshop on Recent Advances in Intrusion Detection, Louvain- 
la-Neuve, Belgium, 14 - 16 September 1998. 
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an attack is in progress (i.e. intrusion detection system alarm indications). From 
the discussion above, information such as IP addresses has been characterized as 
‘personal’ information and unless otherwise exempt, the collection and process- 
ing of this information triggers the application of privacy and data protection 
legislation. This has potentially significant implications with respect to shar- 
ing of the information as an early warning measure, even within organizations, 
especially if they span borders, let alone between organizations. 



8.1 Processing Principles 

The monitoring of network traffic inevitably leads to a conflict between surveil- 
lance (involving the collection of personal information, but being necessary to 
guarantee secure services to the involved parties) and privacy (restricting the 
processing of personal information in accordance with relevant legislation) 0 
Processing, in relation to information or data, covers virtually the entire infor- 
mation lifecycle from collection, through to erasure or destruction of the infor- 
mation when no longer required. Restrictions/limitations on the processing of 
personal information, as found in the selected legislation, derive from the OECD 
Guidelines. A brief review of selected principles follows O 

Both the amount and the type of information collected should be limited to 
that which is necessary to fulfil the purposes identified. Not only is this good 
practice from a privacy point of view, but it also helps minimize the amount 
of data that must be examined by intrusion analysts. Any such data should be 
obtained lawfully, without deceit and where appropriate, with the knowledge or 
consent of the data subject. Personal data should be relevant to the purposes for 
which they are collected. There are a number of reasons for collecting intrusion 
related data, including identification of the source of the activity in order to 
implement countermeasures and for the purposes of prosecution, should this be 
the desired response to an intrusion. Source IP addresses, which are considered 
to be personal data, are relevant to these purposes. 

The purposes for which personal information is collected shall be identified by 
the organization collecting the information at or before the time the information 
is actually collected (purpose specification). Organizations should prominently 
display a warning to the effect that communications may be monitored for the 
purposes of ensuring security (although this may not be the only reason this in- 
formation is collected, it is the primary reason as far as this paper is concerned) . 
Organizations should also indicate that such information may be shared, and 

Biskup, Joachim and Flegel, Ulrich, “Transaction-Based Pseudonyms in Audit Data 
for Privacy Respecting Intrusion Detection”, page 28. 

OECD Guidelines, paragraphs 7 to 10. See also (EU) Data Protection Directive, 
Chapter 2, Section 1, Article 6; (UK) Data Protection Act 1998 (Chapter 29), Sched- 
ule 1 (The Data Protection Principles), principles 1 to 5; (Canada) The Privacy Act, 
Interpretation, paragraphs 4 to 6; (Canada) Personal Information Protection and 
Electronic Documents Act, Part 1, Schedule 1, principles 2 to 6; (Australia) The 
Privacy Act 1988 (as amended). Part III, Information Privacy, Section 14, principles 
1 to 3. 
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should indicate with whom and for what purposes. A number of options exist 
for providing notice (through a banner, as part of web-based forms, as part of an 
account agreement, etc.). When data no longer serve the purpose for which they 
were collected, they should be destroyed or given an anonymous or pseudony- 
mous formP^ 

Whenever personal information is to be used for a purpose not previously 
identified, the new purpose shall be identified prior to such use. Any subsequent 
use should be limited to the fulfillment of those purposes or such others as are 
not incompatible with those purposes EH This is the concept of consistent use - 
i.e. if the subsequent use is consistent with the purpose for which the information 
was originally collected, and if a reasonable individual would see the secondary 
use as consistent, then the information can generally be used for the secondary 
purpose. In the context of IDS data collection, the primary purpose for collecting 
the information is to detect and classify malicious activity against the site being 
monitored by the IDS in order to trigger some form of response to the event, 
which may include law enforcement. Sharing of the information with other sites, 
so that they could perform their own detection, classification and response would 
be entirely consistent with the primary purpose. 



8.2 Dissemination/ Sharing 

As a general statement of principle, all of the cited legislation prohibits the 
sharing of personal information with third parties EB These prohibitions on in- 
formation sharing are based on the OECD principle limiting the use, disclosure 
and retention of personal information, which states that “personal data should 
not be disclosed, made available or otherwise used for purposes other than those 
specified (purpose specification, also known as purpose binding) except: 

a. With the consent of the data subject; or 

b. By the authority of law. EB 

For example, the EU Data Protection Directive requires that transfers of per- 
sonal information only take place when non-EU countries provide an ‘adequate’ 
level of privacy protection. Adequate protection comprises two basic elements: 

EU Data Protection Directive, Article 6(le). 

For example, see: (Canada) The Privacy Act, Article 7(a); (Australia) The Privacy 
Act 1988 (as amended). Principle 10, para le; (UK) Data Protection Act, Schedule 
1, Principle 2; (US) Safe Harbor Principles, Data Integrity Principle. 

For example, see Article 25 of the EU Data Protection Directive, which requires EU 
Member States to take measures to prohibit the transfer of information to countries 
outside of the EU unless those countries can adequately demonstrate that they 
provide an “adequate” level of privacy protection. The UK Data Protection Act 
has identical provisions in Schedule 1, The Data Protection Principles, Part I, The 
Principles (Principle 8). 

OECD Guidelines, paragraph 10. 
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the content of the rules applicable to the protection of privacy and the means for 
ensuring their effective applicationE3 The Data Protection Working Party has 
issued a number of opinions related to the adequacy of the selected legislation!^ 
Having said that, the legislation provides exemptions from this general pro- 
hibition. For instance, the EU Data Protection Directive specifically states that 
the directive does “not apply to the processing of personal data... and in any 
case to processing operations concerning public security, defence. State security 
(including the economic well-being of the State...) and the activities of the State 
in areas of criminal law.” Other conditions under which subsequent use and dis- 
closure can occur, and that may be relevant for private sector organizations, 
include: 

a. The secondary purpose is related to (or consistent with) the primary purpose; 

b. The data subject has provided his/her consent; 

c. Disclosure is required or authorized by or under law; or 

d. There is reason to suspect that disclosure of the information is necessary 
for the prevention, detection, investigation, prosecution or punishment of 
criminal offences Pn 

The knowledge and consent of the individual are required for the collection, 
use, or disclosure of personal information, however there may be certain circum- 
stances in which personal information is collected, used or disclosed without the 
knowledge and consent of the individual. Examples given include collection for 
national security, defence, crime detection, and enforcement of criminal lavO - 
seeking the consent of the individual would defeat the purpose of collecting the 
information. One or more of these categories could certainly cover the collection 
and disclosure of intrusion detection data. 

Data Protection Working Party, Working Document, “Transfers of personal data to 
third countries: Applying Articles 25 and 26 of the EU data protection directive”, 
dated 24 July 1998. 

Data Protection Working Party, “Opinion 4/2000 on the level of protection provided 
by the Safe Harbor Principles”, dated 16 May 2000. See also: “Opinion 2/2001 on 
the adequacy of the Canadian Personal Information Protection and Electronic Doc- 
uments Act”, dated 26 January 2001; and “Opinion 3/2001 on the level of protection 
of the Australian Privacy Amendment (Private Sector) Act 2000” , dated 26 January 
2001 . 

EU Data Protection Directive, Article 3 (Scope), paragraph 2; also Article 13. See 
also: (Canada) Privacy Act, Article 8; (Canada) Personal Information Protection 
and Electronic Documents Act, Division 1 (Protection of Personal Information), 
article 7(3) and Schedule 1, article 4.5.1; (UK) Data Protection Act (1998), Part IV, 
Exemptions; (Australia) Privacy Act 1988, Part III, Information Privacy Principles, 
pages 36 and 37; and (US) “Safe Harbor Privacy Principles”. 

European Commission, “Data Protection: Background Information”, dated 3 
November 1998, page 5 (Exceptions and Limitations). 
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It has been suggested that consent of the individual be obtained even in cases 
of transfers of data to other data controllers, even where there is no change in the 
use or purposely This would apply in cases where intrusion detection informa- 
tion was transferred to other organizations (information sharing being a central 
premise of collective defence). However, as above, there may be circumstances 
where it is inappropriate to obtain the individual’s consent. 

There is also the issue of implied consent involved. For example, consent 
can be implied when a person uses a telephone service for banking services and 
proceeds after hearing a recorded message that the call may be monitored or 
recorded for staff training purposes. In these circumstances, the primary purpose 
is the collection and use of personal information for the provision of banking 
services and the secondary purpose is staff training. Consent for the secondary 
purpose is implied by the person’s action of continuing with the call. Similarly, 
it could be argued that consent for secondary purposes has been given if an 
individual continues to interact with a website after being presented with a 
warning banner that specifies that information collected during the course of 
monitoring will be shared for the purposes of collective defence. 

While it is fairly certain that national security agencies can claim exemp- 
tions from the legislative restrictions on information sharing, it is less obvious 
that private sector organizations can do so. The whole concept of national secu- 
rity has been evolving over the past several years. One of the first documents to 
recognize the changing nature of national security was the report of the Presiden- 
tial Commission on Critical Infrastructure Protection (PCCIP). The Foreword 
to the report states that “the nation is so dependent on our infrastructures 
that we must view them through a national security lens. They are essential to 
the nation’s security, economic health, and social well being. In short, they are 
the lifelines on which we as a nation depend. ’0 Similarly, a recently released 
report by the United States Commission on National Security/21st Century rec- 
ommended the creation of a National Homeland Security Agency, which would 
“assume responsibility for overseeing the protection of the nation’s critical in- 
frastructure, including information technology. ”0 In announcing the creation of 
the Office of Critical Infrastructure Protection and Emergency Preparedness, 
to be placed under the Department of National Defence, the Prime Minister of 
Canada noted that “The protection of Canada’s critical infrastructure from the 
risks of failure or disruption is essential to assuring the health, safety, security 
and economic well-being of Canadians. ”0 

There is a growing recognition that the private sector, as owners and opera- 
tors of the critical infrastructures, should be playing an increasingly important 

Data Protection Working Party, “Opinion 4/2000”, page 6. 

The Report of the President’s Commission on Critical Infrastructure Protection, 
dated October 1997, Foreword, page vii. 

U.S. Commission on National Security/21st Century, “Road Map for National Se- 
curity: Imperative for Change”, (Draft Final Report), dated 31 January 2001, pages 
15 and 17. 

Press Release “Prime Minister Announces Office of Critical Infrastructure Protection 
and Emergency Preparedness”, February 5, 2001, Ottawa, Canada. 
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role in defending these infrastructures. It may be possible to make an argu- 
ment that the private sector is a partner in national security, especially with the 
current emphasis on critical infrastructure protection, and that intrusion mon- 
itoring data could be exempted on that basis. However, there are other, more 
conventional arguments that may be more compelling. For instance, there are 
several articles within the EU Data Protection Directive and Directive 97/66/EC 
(telecommunications) that warrant further examination. 

Article 7(d) and 13(lg) of the EU Data Protection Directive both refer to 
the protection of the vital interests of the data subject or the protection of the 
rights and freedom of others. Article 17 states that data controllers must im- 
plement appropriate technical and organizational measures to protect personal 
data against accidental or unlawful destruction or accidental loss and against 
unauthorized alteration, disclosure or access. Similar provisions exist in most of 
the other cited legislation |3 Common practice indicates that encryption, fire- 
walls and anti-virus protection are among the technical measures being used 
to protect personal data. It is becoming more and more common to see intru- 
sion detection systems included in the protective mix. The sharing of intrusion 
detection information, especially given the highly interconnected nature of in- 
formation infrastructures, may be an appropriate organizational measure that 
will allow private sector organizations to meet their obligations under these ar- 
ticles. Commercial organizations can also obtain a competitive edge if they can 
demonstrate that they provide superior privacy and data protection. 

Similarly, Article 4 of Directive 97/66/EC requires providers of publicly avail- 
able telecommunications services take appropriate technical and organizational 
measures to safeguard security of its services, if necessary in conjunction with 
the provider of the public telecommunications network|3 As part of a general re- 
view, the Commission of the European Communities has put forward a proposal 
for a new directive on a common regulatory framework, which includes more 
inclusive definitions of electronic communications services and networks than 



EU Data Protection Directive, Articles 7, 13 and 17. Similarly, see also (Australia) 
Privacy Act 1988 (as amended), Part III, Section 14, Principle 4(a); (Canada) Per- 
sonal Information Protection and Electronic Documents Act, Schedule 1, Principle 
7; (UK) Data Protection Act 1998, Schedule 1, Principle 7; (US) Safe Harbor Prin- 
ciples, Security Principle. 

(Canada) Telecommunications Act 1993, c.38 (Part I, Article 7(1) refers to the 
telecommunications policy objective of contributing to the protection of the pri- 
vacy of persons, but there do not appear to be any equivalent provisions); (UK) 
Electronic Communications Act 2000 Chapter c.7 (do not appear to be any equiva- 
lent provisions); (Australia) Telecommunications Act 1997 No. 47 of 1997 (Sect 313 
- A carrier or carriage service provider must do the carrier’s best or the provider’s 
best to prevent telecommunications networks and facilities from being used in, or in 
relation to, the commission of offences against the laws of the Commonwealth or of 
the States and Territories); (US) Telecommunications Act 1996 (Section 254(d) - Ev- 
ery telecommunications carrier that provides interstate telecommunications services 
shall contribute ... to the specihc, predictable and sufficient mechanisms established 
by the Commission to preserve and advance universal service (Section 254(f) deals 
with state level)). 
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those currently in Directive 97/66/EC. The requirement to implement appropri- 
ate technical and organizational measures to safeguard security of its services, 
as in Directive 97/66/EC, remains^ As above, the sharing of intrusion detec- 
tion information may be an appropriate organizational measure that will allow 
private sector organizations to meet their obligations under this Article. 

Article 14 of EU Directive 97/66/EC states that member states may restrict 
the scope of obligations and rights outlined in the Directive when such restriction 
constitutes a necessary measure to safeguard national security, defence, public 
security, the prevention, investigation, detection and prosecution of criminal of- 
fences or of unauthorized use of the telecommunications systenj3 With the 
advent of the European Union Draft Convention on CyberCrimqf^ and efforts 
in forums such as the gS there is a growing consensus that hacking activities 
do constitute a crime, although there are still many countries that have not up- 
dated their laws to cover cybercrimes^ It would not be unreasonable, therefore, 
to conclude that the sharing of intrusion detection data is a necessary adjunct to 
the detection and prosecution of cybercrime and could therefore be considered 
exempt from the general prohibitions on sharing of personal information. 

While these articles are taken from EU Directives and are intended primarily 
for EU-based organizations, the global nature of business will result in the appli- 
cation of these directives to North American offices of European organizations, 
and to European branches of North American organizations. 

There are, however, concerns being expressed in some circles that the sharing 
of information could have negative implications for the organizations involved. 
These concerns include: 



Commission of the European Communities, “Proposal for a Directive of the Euro- 
pean Parliament and of the Council on a common regulatory framework for elec- 
tronic communications networks and services”, dated 12 July 2000, Article 2. See 
also: Commission of the European Communities, “Proposal for a Directive of the 
European Parliament and of the Council concerning the processing of personal data 
and the protection of privacy in the electronic communications sector”, dated 12 
July 2000. 

EU Directive 97/66/EC, Article 14. 

European Committee on Crime Problems (CDPC), “Draft Convention on Cyber- 
Crime (Draft No. 25 Rev. 5)”, dated 22 December 2000. See also European Com- 
mittee on Crime Problems (CDPC), “Draft Explanatory Memorandum to the Draft 
Convention on Cybercrime”, dated 14 February 2001 

At the May 2000 meeting of the G8 nations in Paris, France, nations were urged 
“to agree on a world convention on cybercrime and harmonize their laws to crack 
down on hackers, virus writers, software pirates and other Internet fraudsters.” As 
reported in “France: We Must Close ‘Hacker Havens’ ”, Reuters, 15 May 2000. The 
subject was also to be discussed when the G8 nations met in Okinawa in July 2000. 

McConnell International, “Cyber Crime... and Punishment? Archaic Laws Threaten 
Global Information”, dated December 2000. 
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a. Fear of negative publicity and the subsequent effects on share value and 
fear that companies may be liable under antitrust regulationsE^ While the 
sharing of information related to critical infrastructure protection may not 
trigger antitrust legislation, serious consideration should be given to the 
introduction of specific legislation protecting organizations who share this 
type of information; 

b. The potential for lawsuits in the event that there are any real or perceived 
violations of personal privacy as a result of information sharing Cj This is- 
sue hinges on whether or not there is a reasonable expectation of privacy 
related to intrusion detection monitoring and information sharing. Organi- 
zations must make an effort to notify individuals that the system in question 
is monitored and that the resulting information (as it relates to suspicious 
or malicious activity) will be shared for the purposes of infrastructure pro- 
tection. They should also make an effort to convince individuals that the 
sharing of selected information is actually necessary to ensure that the ser- 
vice providers can meet their obligations to protect the interests of the indi- 
vidual. If they can do this, then there should be few if any concerns about 
violations of privacy; and 

c. The fear that any information shared with a federal government agency 
would be subject to disclosure under various Freedom of Information or 
Access to Information Acts, despite the provision for exemptions for infor- 
mation related to investigations, national security, etc01t may be appropri- 
ate to introduce additional exemptions under these acts aimed specifically at 
protecting such information against disclosure, particularly for organizations 
in the private sector who may not be able to make a convincing argument 
that they are sharing this information for national security reasons. 

Until some provisions are made to address these concerns, there may be reluc- 
tance on the part of organizations to freely share intrusion information, despite 
the apparent lack of restrictions on such sharing under the above legislation. The 
author was unable to find any provisions within the cited legislation that would 
address these concerns - this may be the sublet of separate legislation or it may 
be an issue that has not yet been addressed CJ 



Holland, Jesse J., “Companies Won’t Help National Cybersecurity Without 
Waivers”, The Associated Press, 22 June 2000. 

Johnston, Margret, “Commerce Department Tries to Boost ‘Safe Harbor’ Adoption”, 
IDG News Service, dated 05 January 2001. 

For example, see: (Canada) Access to Information Act (R.S. 1985, c.A-1), Exemp- 
tions; (UK) Freedom of Information Act 2000, Chapter 36, Part II; (Australia) Free- 
dom of Information Act 1982, Part IV; and (US) The Freedom of Information Act, 
5 U.S.C. §552, As Amended By Public Law No. 104-231, 110 Stat. 2422, Section 
522(b). 

This is an issue that is being considered at the time of this paper. See, for instance, 
“Senator Wants to Aid Cyber Security by Secrecy”, by Reuters, dated 07 May 2001. 
This is also an issue being examined in Canada. 
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9 Conclusion 

The increasingly global interconnection of information systems to create the 
Global Information Infrastructure (GII) is forcing the issue of ‘shared connection, 
shared risk’ to the forefront of discussion. This in turn implies the notion of 
‘shared risk, shared responsibility’ for dealing with the risk. One method of 
addressing shared risk is to share information concerning intrusion detection, 
as a means of facilitating early warning, response and investigation within the 
security community. 

There is a considerable degree of consistency in the definitions ‘personal in- 
formation’ or ‘personal data’ in the cited legislation. In all cases, the definitions 
are worded in such a way as to permit fairly broad interpretation as to what con- 
stitutes personal information or data. In some instances, such as in Ganada, this 
is exactly how the definition has been interpreted. This leads to the conclusion 
that IP addresses, because of the potential to link them with an identified or 
identifiable individual, also fall within the definition. It should be noted, however, 
that this is a personal opinion and that the opinion has not yet been validated by 
being tested in case law to the best of the author’s knowledge. In the event that 
this is a valid interpretation of the legislation, any processing of this information 
would invoke the appropriate privacy or data protection legislation. 

Although all of the cited legislation generally prohibits the sharing of personal 
information, they do make exceptions for reasons of national security and law 
enforcement. There are also provisions calling upon service providers to protect 
their networks and services that could be used as justification for sharing infor- 
mation. It can be argued, successfully in the author’s opinion, that exemptions 
provided in the legislation for sharing of personal information can be extended 
to the sharing of intrusion detection information. There are, however, other con- 
cerns, such as liability under antitrust regulations, which may hinder information 
sharing, even in the apparent absence of any legislative restrictions. In order to 
create a climate in which organizations are comfortable sharing intrusion de- 
tection information, or any other intrusion related information for that matter, 
these concerns, whether real or not, must be addressed. 

References 

1. Alexander, Jim, Program Director SII, Chief Information Officer Branch, Treasury 
Board of Canada Secretariat, “Overview of Strategic IM/IT Infrastructure Initia- 
tive”, a presentation to the Fifth Annual Government on the Net conference, dated 
24 November 1999. Presentation available at 

http : / /www .nrc . ca/f orum/govnet 99/pre sent at ions/alexanderj .pdf 

2. (Australia) Freedom of Information Act 1982, Act No. 3 of 1982 as amended. This 
compilation was prepared on 22 June 2001 taking into account amendments up to 
Act No. 30 of 2001. Available at 

http : / /scaleplus . law.gov. au/html/pasteact/O/58/pdf /F0I82 .pdf 

3. (Australia) The Privacy Act 1988 (Act No. 119 of 1988 as amended). The compi- 
lation used was prepared 24 May 2001 incorporating amendments up to Act No. 
24 of 2001. Available at 

http : / /scaleplus . law.gov. au/html/pasteact/O/157/pdf /Privacy88 .pdf . 



168 



S.R. Johnston 



4. (Australia) Telecommunications Act 1997 No. 47 of 1997. Available at 
http : //scaleplus . law.gov. au/html/pasteact/2/3021/top .htm, 

5. (Australia) Privacy Amendment (Private Sector) Act 2000 (Act No. 155 of 2000), 
assented to 21 December 2000. Available at 

http : / /scaleplus . law.gov. au/html/comact/10/6269/pdf/155of 2000 .pdf . 

6. Biskup, Joachim and Flegel, Ulrich, “Transaction-Based Pseudonyms in Audit 
Data for Privacy Respecting Intrusion Detection”. In H. Debar, L. Me and F. Wu 
(Eds.): Proceedings of Recent Advances in Intrusion Detection 2000, pages 28 - 
48, Springer- Verlag Berlin Heidelberg, 2000. Also available electronically at 
http : / /link. springer . de/link/service/series/0558/papers/1907/ 
19070028.pdf (subscription required). 

7. Buschkes, Roland and Kesdogan, Dogan, “Intrusion Detection and User Privacy 
- A Natural Contradiction?”, slides presented at the First International Work- 
shop on Recent Advances in Intrusion Detection, Louvain-Ia-Neuve, Belgium, 
14 - 16 September 1998, available at http://www.raid-symposium.org/raid98/ 
Prog_RAID98/Full_Papers/Bueschkes_slides . pdf 

8. Beardwood, John, “Privacy Issues”, paper prepared for the First Annual IT Law 
Spring Training Program, 27 - 29 April 2000, sponsored by the Law Society of 
Upper Canada Osgoode Hall, Toronto, Canada. 

9. Boucher, Phillippe; Shostack, Adam; and Goldberg, Ian; “Freedom System 2.0 Ar- 
chitecture”, Zero-Knowledge Systems, Inc., 18 December 2000. Available at http: 
/ /www . freedom.net/info/whitepapers/Freedom_System_2_Architecture .pdf 

10. (Canada) Access to Information Act (R.S. 1985, c.A-1), updated to 31 December 
2000. Available at http : //laws, justice/gc/ca/en/ A- 1/index. html, 

11. (Canada) The Privacy Act (R.S. 1985, c. P-21 (The Privacy Act), updated to 30 
April 2000. Available at 

http : / /canada. justice . gc . ca/en/laws/P-21/text .html. 

12. (Canada) Telecommunications Act 1993, c.38 (assented to 23 June 1993). Available 
at http : / /laws .justice .gc . ca/en/T-3 .4/88772 .html 

13. (Canada) Personal Information Protection and Electronic Documents Act 2000, c. 
5. Available at http : //canada. justice . gc . ca/en/laws/P-8 . 6/text .html 

14. Department of Foreign Affairs and International Trade (Canada), Economic and 
Trade Analysis Division, “Second Annual Report on Canada’s State of Trade 
(Trade Update 2001)”, dated May 2001. Report available at 

http : / /www . df ait-maeci .gc . ca/eet/state_of _trade/trade_upd2001-e .pdf 

15. Data Protection Working Party, “Opinion 4/2000 on the level of protection 
provided by the “Safe Harbor Principles” ” , dated 16 May 2000. Available at 
http : / /europa. eu. int/comm/ internal_market/en/dataprot/wpdocs/ 

wp32en . pdf 

16. Data Protection Working Party, “Opinion 7/2000 On the European Commission 
Proposal for a Directive of the European Parliament and of the Council concern- 
ing the processing of personal data and the protection of privacy in the electronic 
communications sector or 12 July 2000 COM (2000) 385”, dated 2 November 

2000. Available at http://europa.eu.int/comm/internal_market/en/dataprot/ 
wpdocs/wp36en.pdf 

17. Data Protection Working Party, “Opinion 2/2001 on the adequacy of the Canadian 
Personal Information Protection and Electronic Documents Act” , dated 26 January 

2001. Available at http://europa.eu.int/comm/internal_market/en/dataprot/ 
wpdocs/wp39en.pdf 



The Impact of Privacy and Data Protection Legislation 169 



18. Data Protection Working Party, “Opinion 3/2001 on the level of protection of 
the Australian Privacy Amendment (Private Sector) Act 2000”, dated 26 January 
2001. Available at http://europa.eu.int/comm/internal_market/en/dataprot/ 
wpdocs/wp40en.pdf 

19. Data Protection Working Party, Working Document, “Transfers of personal data to 
third countries: Applying Articles 25 and 26 of the EU data protection directive”, 
dated 24 July 1998. Available at http://europa.eu.int/comm/internal_market/ 
en/dataprot/wpdocs/wpl2en.pdf 

20. Data Protection Working Party, Working Document, “Privacy on the Internet - 
An Integrated EU Approach to On-line Data Protection”, dated 21 November 
2000. Available at http://europa.eu.int/comm/internal_market/en/dataprot/ 
wpdocs/wp37en.pdf 

21. Directive 95/46/EC of the European Parliament and of the Council of 24 October 
1995 on the protection of individuals with regard to the processing of personal 
data and on the free movement of such data ((EU Data Protection Directive). 
Online text available at http://europa.eu.int/eur-lex/en/lif/dat/1995/en_ 
395L0046.html Authoritative text of the Directive can be found in the Official 
Journal of the European Communities of 23 November 1995 No. L 281 pp. 0031 - 
0050. 

22. Directive 97/66/EC of the European Parliament and of the Council of 15 
December 1997 concerning the processing of personal data and the protec- 
tion of privacy in the telecommunications sector. Online text available at 
http : //europa. eu. int/eur-lex/en/lif /dat/1997/en_397L0066 .html. Authori- 
tative text of the Directive can be found in the Official Journal of the European 
Communities of 30 January 1998 No. L024 pp. 0001 - 0008. 

23. European Commission, “Data Protection: Background Information”, dated 3 
November 1998. Available at http://europa.eu.int/comm/internal_market/en/ 
media/ dataprot/backinf o/inf o . htm, 

24. European Commission, “Proposal for a Directive of the European Parlia- 
ment and of the Council on a common regulatory framework for electronic 
communications networks and services”, dated 12 July 2000. Available at 
http : / /europa. eu. int/ISPO/ inf osoc/telecompolicy/ 

review99/ com2000-393en . pdf . 

25. European Commission, “Proposal for a Directive of the European Parliament and 
of the Council concerning the processing of personal data and the protection of 
privacy in the electronic communications sector” , dated 12 July 2000. Available at 
http : / /europa. eu. int/ISPO/ inf osoc/telecompolicy/review99/ 
com2000-385en.pdf 

26. European Committee on Crime Problems (CDPC), “Draft Convention on Cyber- 
Crime (Draft No. 25 Rev. 5)”, dated 22 December 2000. Available at 

http : / /conventions . coe . int/treaty/EN/projets/ cybercrime25.htm 

27. European Committee on Crime Problems (CDPC), “Draft Explanatory Memoran- 
dum to the Draft Convention on Cybercrime”, dated 14 February 2001. Available 
at http : / /conventions . coe . int/treaty/EN/projets/CyberRapex7 .htm. 

28. Holland, Jesse J., “Companies Won’t Help National Cybersecurity Without 
Waivers”, dated 22 June 2000, The Associated Press. Available at 

http : / /www . startext .net/news/doc/1047/1 : C0MP56/ 1 : C0MP560622100.html 

29. Johnston, Margret, “Commerce Department Tries to Boost ‘Safe Harbor Adoption’ 
”, 05 January 2001, IDG News Service. Available at 

http : / /www . computerworld. com/cwi/story/0, 1199 , NAV47_ST055924, 00 .html 



170 



S.R. Johnston 



30. Lundin, Emilie and Jonsson, Erland, “Privacy vs. Intrusion Detection Analysis”, 
as submitted to the Second International Workshop on the Recent Advances in 
Intrusion Detection, hosted by Purdue University CERIAS, West Lafayette, Indi- 
ana, USA, September 7-9, 1999, available at 

http : / /www . raid- symposium . org/ raid99/PAPERS/Lundin . pdf , 

31. McConnell International, “Cyber Crime... and Punishment? Archaic Laws 
Threaten Global Information”, dated December 2000. PDF version of report avail- 
able at http : //www .mcconnellinternational . com/services/CyberCrime .pdf. 

32. Organization for Economic Cooperation and Development (OECD), “Guidelines 
on the Protection of Privacy and Transborder Flows of Personal Data” , dated 23 
September 1980. Available at 

http : / /www . oecd. org/dsti/sti/ it/ secur/prod/PRIV-EN.HTM, 

33. Press release, “Prime Minister Announces Office of Critical Infrastructure Pro- 
tection and Emergency Preparedness”, dated 5 February 2001, Ottawa, Canada. 
Available at http: //pm. gc . ca/def ault . asp?Language=E\&Page=newsroom 
\&Sub=NewsReleases\&Doc=emergency . 20010205_e.htm. 

34. Report of the President’s Commission on Critical Infrastructure Protection, dated 
October 1997. Available at 

http : //www . ciao . gov/CIAO_Document_Library/PCCIP_Report . pdf 

35. Reuters, “France: We Must Close ’Hacker Havens’ ”, dated 15 May 2000. Available 
at http : / /www. zdnet . co.uk/news/2000/ 19/ns- 15382 .html 

36. Reuters, “Senator Wants to Aid Cyber Security by Secrecy”, dated 07 May 2001, 
available at http : //www. thestandard. com/article/0 , 1902 , 24269 , 00 .html 

37. Sobirey, Michael, Fischer-Hubner, Simone and Rannenberg, Kai, “Pseudonymous 
Audit for Privacy Enhanced Intrusion Detection”, pp. 151-163 in Louise Yn- 
gstrom, Jan Carlsen: Information Security in Research and Business; Proceed- 
ings of the IFIP TCll 13th International Information Security Conference (SEC 
’97): 14-16 May 1997, Copenhagen, Denmark. Also available at http://www.iig. 
uni-freiburg.de/~kara/publications/SoFiRa_97 . IFIP_SEC . 2.pdf 

38. Sommer, Peter, “Intrusion Detection Systems as Evidence”, as presented at the 
First International Workshop on the Recent Advances in Intrusion Detection, 
14 - 16 September 1998, Louvain-la-Neuve, Belgium. Available at http: //www. 
raid- symposium . org/raid98/Prog_RAID98/Full_Papers/Sommer_text . pdf 

39. Supreme Court of Canada, Dagg v. Canada (Minister of Finance), [1997] 2 
S.C.R. 403. Decision posted at Faculty of Law, University of Montreal, Mon- 
treal, Canada (http: //www. lexum.umontreal . ca/csc-scc/en/pub/1997/vol2/ 
html/ 19997scr2_0403 . html) . 

40. The Office of Critical Infrastructure Protection and Emergency Preparedness, 
notes on Roles and Responsibilities. Available at http://www.epc-pcc.gc.ca/ 
whoweare/ index_e . html . 

41. The Right Honourable Jean Chretien, Prime Minister of Canada, in his “Re- 
sponse to the Speech from the Throne”, October 13, 1999, Ottawa, Ontario. Doc- 
ument available from http : //www. pm. gc . ca/def ault . asp?Language=E\&Page= 
newsroom\&Sub=Speeches\&Doc=speechesl99910131085_e .htm 

42. Treasury Board of Canada Secretariat, “Strategic Directions for Information Man- 
agement and Information Technology: Enabling 21st Century Service to Canadi- 
ans”, dated 18 October 1999. Available at 

http : / /www . tbs- set . gc . ca/Pubs_pol/ ciopubs/TB_0IMP/sdimitl_e .html, 

43. (United Kingdom) Freedom of Information Act 2000, Chapter 36, dated 30 Novem- 
ber 2000. Available at 

http : / /www . legislation.hmso.gov.uk/ acts/ acts2000/20000036 .htm 




The Impact of Privacy and Data Protection Legislation 171 



44. (United Kingdom) Data Protection Act 1998 (Chapter 29), dated 16 July 1998. 
Outline of document, with links, available at 

http : / /www . legislation.hmso.gov.uk/ acts/ actsl998/ 19980029 .htm 

45. (United Kingdom) Electronic Communications Act 2000, 2000, Chapter c.7 (25 
May 2000). Available at 

http : / /www . legislation.hmso.gov.uk/ acts/ acts2000/20000007 .htm 

46. (United States) Department of Commerce, “Safe Harbor Privacy Princi- 
ples”, dated 21 July 2000. Available at http://www.export.gov/safeharbor/ 
SHPRIHCIPLESFINAL.htm. More information on the Safe Harbor program is avail- 
able at http : / /www . export . gov/ saf eharbor / 

47. (United States) National Commission on National Security/21st Century, “Road 
Map for National Security: Imperative for Change”, draft final report dated 31 
January 2001. Available at http://www.nssg.gov/phaseIII.pdf. 

48. (United States) The Freedom of Information Act, 5 U.S.C. §552, As Amended By 
Public Law No. 104-231, 110 Stat. 2422. Available at 

http : / /f oia. state .gov/f oia. asp 

49. (United States) Telecommunications Act of 1996. Available at http : //f rwebgate . 
access .gpo . gov/ cgi-bin/getdoc . cgi?dbname=104_cong_bills\&docid=f : 
s652enr . txt . pdf 



Experiences with Specification-Based Intrusion 

Detection* 



Prem Uppuluri and R. Sekar 

Department of Computer Science 
SUNY at Stony Brook, NY 11794 
{prem, sekar}@cs . sunysb.edu 



Abstract. Specification-based intrusion detection, where manually specified pro- 
gram behavioral specifications are used as a basis to detect attacks, have been 
proposed as a promising alternative that combine the strengths of misuse detec- 
tion (accurate detection of known attacks) and anomaly detection (ability to detect 
novel attacks). However, the question of whether this promise can be realized in 
practice has remained open. We answer this question in this paper, based on our 
experience in building a specification-based intrusion detection system and exper- 
imenting with it. Our experiments included the 1999 DARPA/AFRL online evalu- 
ation, as well as experiments conducted using 1999 DARPA/ Lincoln Labs offline 
evaluation data. These experiments show that an effective specification-based IDS 
can be developed with modest efforts. They also show that the specification-based 
techniques live up to their promise of detecting known as well as unknown attacks, 
while maintaining a very low rate of false positives. 



1 Introduction 

With the growing number of attacks on network infrastructures, the need for techniques 
to detect and prevent attacks is increasing. Intrusion detection refers to a broad range of 
techniques that defend against malicious attacks. Intrusion detection techniques gener- 
ally fall into one of the following categories: misuse detection, anomaly detection and 
specification-based detection. The main advantage of misuse detection is that it can ac- 
curately detect known attacks, while its drawback is the inability to detect previously 
unseen attacks. Anomaly detection, on the other hand, is capable of detecting novel 
attacks, but suffers from a high rate of false alarms. This occurs primarily because pre- 
viously unseen (yet legitimate) system behaviors are also recognized as anomalies, and 
hence flagged as potential intrusions. 

Specification-based techniques have been proposed as a promising alternative that 
combine the strengths of misuse and anomaly detection. In this approach, manually 
developed specifications are used to characterize legitimate program behaviors. As this 
method is based on legitimate behaviors, it does not generate false alarms when unusual 
(but legitimate) program behaviors are encountered. Thus, its false positive rate can 
be comparable to that of misuse detection. Since it detects attacks as deviations from 
legitimate behaviors, it has the potential to detect previously unknown attacks. 
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Although the promise of specification-based approach has been argued for some 
time, the question of whether these benefits can be realized in practice has remained 
open. Some of the questions that arise in this context are: 

- How much effort is required to develop program behavioral specifications? How do 
these efforts compare with that required for training anomaly detection systems? 

- How effective is the approach in detecting novel attacks? Are there classes of attacks 
that can be detected by specification-based techniques that cannot be detected by 
anomaly detection or vice-versa? 

- Can it achieve false alarm rates that are comparable to misuse detection? 

We provide answers to the above questions in this paper, based on our experience 
in building a specification-based intrusion detection system and experimenting with 
it. Our experiments included (a) the 1999 DARPA/AFRL online evaluation, (b) the 
1999 DARPA/Lincoln Labs offline evaluation data, and (c) several locally-developed 
experiments. These experiments show that an effective IDS can be developed with modest 
specification development efforts, of the order of tens of hours for many security-critical 
programs on Solaris. Moreover, these efforts need to be undertaken just once for each 
operating system - further customization on the basis of individual hosts or installations 
seems to be unnecessary. This contrasts with anomaly detection systems that typically 
need training/tuning for each host/system installation. 

Our experiments show that the specification-based techniques live up to their promise 
of detecting known as well as unknown attacks, while maintaining a low rate of false 
positives. In particular, we were able to detect all the attacks without any false positives in 
the online evaluation. In the offline evaluation, we could detect 80% of the attacks using 
specifications that characterized legitimate program behaviors. The remaining 20% of 
the attacks did not cause program (or system) misbehavior, and it is debatable whether 
they constitute attacks at all. Nevertheless, we were able to easily model these attacks as 
misuses. Augmented with these misuse specifications, our system was able to achieve 
100% detection with no false alarms in the offline evaluation as well. 

The rest of this paper is organized as follows. We begin with an overview of our 
specification-based intrusion detection technique in Section Q Following this, we de- 
velop a methodology for specification development in SectionQ In Section|^ we report 
our experimental results. Section lUfurther analyzes our results. Finally, we summarize 
our conclusions in Sectional 



2 Background 

In IKITII we described our approach to specification based intrusion detection. Central to 
our approach is the observation that intrusions manifest observable events that deviate 
from the norm. We extend the current state of the art in event-based intrusion detection 
by developing a domain-specific language called behavioral monitoring specification 
language (BMSL) [ 0 . BMSL enables concise specifications of event based security- 
relevant properties. These properties can capture either normal behavior of programs 
and systems, or misuse behaviors associated with known exploitations. 
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Fig. 1. Runtime view of the system. Pi , . . . , are processes ; Sy slog Mon is a system log watcher. 

In our approach, we compile BMSL specifications into efficient detection engines 
( DE ) 0] . For network packets, BMSL specifications are based on packet contents, and for 
system calls, BMSL specifications are based on system calls and the values of system call 
arguments. In both contexts, BMSL supports a rich set of language constructs that allow 
reasoning about not only singular events, but also temporally related event sequences. 
In this paper, we are concerned only with system call events. 

The overall architecture of our intrusion detection/response system is shown in Fig- 
ured For a given event stream such as packets or system calls, an interceptor component 
placed in the stream provides efficient interception of raw events. The interceptors de- 
liver raw event streams to a runtime environment (RTF) associated with each stream. 
Typically, a single detection engine monitors each defended process. 

Note that in the figure, we show a runtime environment for system calls, one for 
network packets and another for log file entries. The log file entries are made by a syslog 
monitor program (syslog mon). Although our specification based approach is capable of 
processing event data from such diverse sources, the discussion in the rest of this paper 
pertains only to system call events. 



2.1 Behavior Modelling Specification Language (BMSL) 

BMSL is a core language that we have designed for developing security-relevant behav- 
ior models. Specifications in BMSL consist of rules of the form pat action, where 
pat is a pattern on event sequences, otherwise known as histones’, and action specifies 
the responses to be launched when the observed history satisfies pat. Observe that we 
typically initiate responses when abnormal behaviors are witnessed; thus, pat compo- 
nents of rules usually correspond to negations of properties of normal event histories. 

System Call Events. In the context of system calls, we define two events corresponding 
to each system call. The first event, which is given the same name as that of the system 
call, corresponds to the invocation of the system call. The arguments to the event are 
exactly the set of arguments to the system call. The second event corresponds to the 
return from the system call, and its name is obtained by suffixing _exit to the name 
of the system call. The arguments to the exit event include all of the arguments to the 
system call, plus another argument that captures the return value from the system call. 
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Note that the system call entry and exit events always occur in pairs. To minimize 
clutter, we use the convention that a system call entry (or exit) event can stand for both 
the entry and exit events. 

The pattern language: Regular Expressions over Events (REE). As a language that 
captures properties of (event) sequences, our pattern language draws on familiar concepts 
from regular expressions. It extends these concepts from sequences of characters to 
events with arguments. 

The simplest REE pattern captures single-event occurrences (or non-occurrences): 

- occurrence of single event: e{x \ , ..., Xn)\cond is satisfied by the (single-event) his- 
tory e{vi, ..., Vn) if cond evaluates to true when variables xi, ..., are replaced 
by the values v\, ...,Vn- 

- occurrence of one of many events: ifi||El2|| • • • \ \En, where each Ei captures an 
occurrence of a single event, is satisfied by a history El if any one of Ei, En is 
satisfied by H. 

- event non-occurrence: !(£li||i?2|| • • • \\En) is satisfied by H if none of Ei, En 
are satisfied by H. Here again, Ei, ■..,En denote an event pattern of the form 
e(xi, ..., Xn)\cond. 

These primitive event patterns can be combined using temporal operators to capture 
properties of event sequences as follows: 

- sequencing: pati;pat2 is satisfied by i/ii/2 if Hi and iJ2 satisfy pati and pat2 
respectively. 

- alternation: pati \ \ pat2 is satisfied by iJ if iJ satisfies pati or pat2- 

- repetition: pat* is satisfied by H1H2 ■ ■ ■ Hn where each Hi satisfies pat. 

When a variable occurs multiple times within a pattern, an event history will satisfy the 
pattern only if the history instantiates all occurrences of the variable with the same value. 
Eor instance, the pattern Ci (x) ; 62 (a;) will not be satisfied by the event history ei (a) 62 (&) , 
but will be satisfied by 61(0)62(0). This ability of REE’s to remember event argument 
values (for later comparison with arguments of subsequent events) makes them much 
more expressive than regular languages. Their expressive power is in fact comparable 
to that of attribute grammars rather than regular grammars. 

Based on the notion of satisfaction defined above, we define the notion of an event 
history H matching a pattern p: we say that H matches p if any suffix of H matches p. 
If we need to anchor the match (i.e., constrain the match to occur from the beginning of 
the history H), we introduce a special event begin at the beginning of the pattern. All 
histories begin implicitly with the event begin. 

Actions. As is well known in the context of finite-state automata, some pattern-matching 
operations are conveniently stated using regular expressions, while there are others that 
are more amenable to a state-machine formulation. Since the same holds true in the 
case of our behavior specifications as well, our language permits explicit introduction 
of state variables. These variables may be assigned in the action component, or tested in 
the pattern component of a rule. 

In addition to variable assignments, the action component of a rule may invoke 
external functions that are provided by the RTE. These functions can be used to invoke 
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response actions that are aimed at preventing and/or containing damage due to an attack. 
External functions can also be used to express computations that are not easily described 
in BMSL, but can be coded in a general-purpose programming language such as C-H-. 



2.2 Example Specifications 

As a first example, we illustrate a pattern that restricts a process from making a certain 
set of system calls: 

execvel I connect I Ichmodl IchownI I creat I I sendto I Imkdir — >■ termO 
Note that we have omitted system call arguments, as they are not used elsewhere in the 
specification. (Sometimes, we will use “. . .” to denote unused event arguments.) Also note 
that in this example, an external function termO is being used to terminate a process 
that makes one of the disallowed system calls. Other response actions, such as aborting 
the disallowed system call, or logging a message, are also possible. 

As a second example, consider the following specification that restricts the files that 
a process may access for reading or writing: 
admFiles = {"/etc/utmp" , "/etc/passwd"} 

open(f, mode) I (realpathCf l^admFiles I I mode7^D_RDDNLY) — >■ termO 
Here, the auxiliary function realpath is used to convert a filename into a canonical form 
that does not make use of the special characters “ . ” and “ . . ”, or symbolic links. 

To illustrate the use of sequencing operators, consider the following pattern that 
asserts that a program never opens and closes a file without reading or writing into it. 
Before defining the pattern, we define abstract events that denote the occurrence of one 
of many events. Occurrence of an abstract event in a pattern is replaced by its definition, 
after substitution of parameter names, and renaming of variables that occur only on the 
right-hand side of the abstract event definition so that the names are unique. 
openExit(fd) ::= open_exit ( . . . , fd) I I creat_exit ( . . . , fd) 
rwDp(fd) ::= read(fd) I I readdir(fd) I I write(fd) 
openExit (f d) ; ( ! rwOp(fd) ) * ; close (f d) —>■••• 

Although regular expressions are not expressive enough to capture balanced parenthesis, 
note that the presence of variables in REE enables us capture the close system call 
matching an open. Note that such matching open and close operations cannot be captured 
even by context-free grammars. 



3 Specification Development 

Our approach for specification development consists of the following steps: 

1. Developing generic specifications: Generic specification is a specification that is 
parameterized with respect to system calls as well as their arguments. By appro- 
priately instantiating these parameters, such specifications can be used to monitor 
almost any program. 

2. Securing program groups: In this step, we strengthen generic specifications for 
classes of programs that have similar security implications, e.g., setuid programs 
and daemons. 
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3. Developing application-specific specifications: Some programs, such as servers that 
can be accessed from remote sites, will likely be attack targets more frequently than 
other programs. For such applications, we can increase the effectiveness of the 
intrusion detection system by developing more precise specifications. 

4. Customizing specifications for an operating system/site: Specifications obtained 
from the previous steps are customized to accommodate variations in operating 
systems and site specific security policies. 

5. Adding misuse specifications: It is likely that the detection of some attacks requires 
knowledge about attacker behavior. In such cases, a pure specification-based ap- 
proach (wherein only legitimate program behaviors are specified) may not be suf- 
ficient. Therefore, one can augment such pure specifications with misuse patterns 
that can capture features of specific attacks. 

We note that in progressing from step 1 to step 5, we are developing more and 
more precise specifications of the behavior of a program. Less precise specifications 
mean lower specification development effort, but can negatively impact the effectiveness 
of the approach in terms of missed attacks as well as increased false alarms. More 
precise specifications increase the effectiveness of the system at the cost of increased 
specification development effort. We discuss these tradeoffs further in the next section. 
Below, we proceed to describe the five steps mentioned above in greater detail. 

3.1 Step 1: Developing Generic Specifications 

The first step in the development of generic specifications is to group system calls of 
similar functionality. This allows us to consider a smaller number of system call groups 
(few tens) while writing specifications, rather than dealing with a few hundred system 
calls. Grouping of system calls also helps in developing portable specifications, because 
the role of each of these groups tends to be constant across different operating systems, 
even though the system calls within the groups may be different. 

For the purpose of developing generic specifications, we have identified 23 groups, 
further organized into 9 categories. Below, we provide a selected subset of these 23 
groups, drawn from 5 categories. The complete listing can be found in Q. 

- File Access Operations 

• W riteOperations {path) : This group includes system calls such as open (with 
open for write option) and creat that change the contents of a file named path. 

• ReadOperations{path) : This group includes system calls which perform read 
operations on a file specified in fhe parameter path. 

• FileAttributeChangeOps{path): This group includes system calls such as 
chgrp and chmod. 

• FileAttributeCheckOps{path) : System calls which check file aftribufes (e.g., 
permissions and modification times) are included in this group. 

- Process Operations 

• ProcessCreation: This group includes system calls fork and execve which 
create or execute a new process. 

• Processinterference: These are system calls such as kill which enable one 
process to alter the course of execution of another process. 
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1. WriteOperations (pat/i) \path G fileWriteList — >■ termO 

2. ReadOperationsipath) \path G fileReadList ^ termO 

3. (FileAttributeChangeOps (pat/i) {path G f ileAttributeC hangeList 

— ^ termO 

4. execveiprog) \prog G fileExecList ^ termO 

5. Processinterf erence — >■ termO 

6. (ConnectCalls || AcceptCalls) — >■ termO /* * Remove for clients/servers */ 

7. (Privileged ) termO 

8. SetResourceAttributes termO 



Fig. 2. Sample generic specifications 



- Network Calls 

• ConnectCalls: These are system calls made by a client to connect to a server. 

• AcceptCalls: These system calls are made by a server to accept a connection. 

- Setting resource attributes: These are system calls which set or change resource 
attributes such as scheduling algorithms and scheduling parameters. 

- Privileged Calls: Includes system calls such as mount and reboot that require root 
privileges to run. 

Based on the above classification, we have developed a generic specification as 
shown in Figure|21 It is parameterized with respect to (a) the definition of which system 
calls are in the each of the system call groups mentioned above, and (b) lists of files that 
may be read or modified by a program. Of these, the definition of (a) will be provided 
in step 4. File lists are given certain default values in the generic specification, and will 
be further refined in steps 2 through 4. 

3.2 Step 2: Securing Program Groups 

Certain groups of programs have similar security properties. We can exploit these com- 
monalities to develop specifications that can be reused among programs within the group. 
For instance all setuid to root programs should be restricted from opening or changing 
attributes on arbitrary files, and executing arbitrary programs. This can be achieved by 
customizing the file lists used in the generic specification. (The customized lists obtained 
in this manner for the entire group of setuid programs may have to be further refined for 
individual programs in Step 4.) 

Most setuid programs expect arguments (provided either through the command line 
or through environment variables) of a bounded size. Hence we add the following rule 
to the specification for setuid programs: 
execve(path,argv,envp ) I checkSize(path,argv,envp,max) — ^ termO 
The function checkSize checks if the path argument size is less than the system-defined 
constant PATH_MAX, and that each of the command-line and environment arguments are of 
size less than max. The parameter max may have to be customized for individual programs. 

As another example, consider server programs that perform user-authentication. In 
such programs, a large number of failed login attempts within a short period of time is 
considered abnormal behavior. The discussion below is set in the context of the telnet 
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server, but is applicable to other programs such as FTP as well. Note that programs such 
as telnetd restrict users to a small number of login attempts (usually three), after which 
the server terminates. Thus, in order to make a large number of login attempts, a user 
would have to cause many instances of telnetd to be spawned in succession, with each 
instance restricting the user to a small number of attempts. Therefore, we develop the 
following rule for the inetd superserver, which counts the number of telnetd instances 
spawned by inetd within a short period of time. 

execve (prog) I prog = "in. telnetd" && tooManyAttempts () — >■ 
logC'too many failed logins") 

We are currently adding better language support for capturing the notion of “too many 
occurrences within a short time,” based on our earlier work in network intrusion detection 
Q . Meanwhile, for the purpose of the experiments described in this paper, we have relied 
on an external function tooManyAttempts, whose implementation was provided in C-H-, 
to capture this notion. 

Note that the above rule simply counts the number of telnetd instances spawned, 
without any consideration of whether these instances led to a failed login or not. We 
therefore add the following rule to the telnetd specification, which uses a function 
resetAttempt to reset all of the counters involved whenever a successful login is com- 
pleted, which is signified by the execution of a setuid or setreuid system call. 

(setuid II setreuid) — resetAttempt () 

Currently, our approach for customizing specifications is based on manual editing. Lan- 
guage support for such customization is a topic of current research. 



3.3 Step 3: Developing Application-Specific Specifications 

We can further refine specifications for individual applications in order to provide better 
security, especially for network servers. FlgureOlshows a partial specification for an FTP 
server (f tpd). (See |jHI for a more complete model that contains five additional rules.) 
Our starting point for this model was the documentation provided in FTP manual pages. 
From there, we identified the principal security-related system calls made by ftpd and 
plausible sequencing orders for their execution to obtain the model. For ftpd, completion 
of user login is signified by the first setreuid system call executed, and this userid is 
stored in loggedUser by the first rule. Similarly, the name of a client host is extracted from 
a return argument when the getpeername system call exits, and remembered in clientIP 
by the second rule. The third and fourth rules restrict the behavior of the ftp server based 
on whether user login has been completed or not. Rules 5 and 7 capture properties that 
must be generally adhered to by servers such as ftpd: they must permanently reset 
their userid using setuid (rule 5), and any file opened with superuser privileges must be 
explicitly or implicitly closed (rule 7) before executing other programjj. Rule 6 captures 
the property that when ftpd resets its userid to 0 (i.e., superuser in UNIX) it must do 
so for executing a small set of operations that deal with binding to low-numbered ports. 
Finally, rule 8 restricts ftpd from connecting to arbitrary hosts. 

^ These two rules could have been made part of the specification for the group of server programs 
such as telnet and ftp, but we did not do so for the experiments reported in this paper. 
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1. ( ! setreuid) * ; setreuidCr ,e) — >■ loggedUser := e 

2. ( ! getpeername) * ; getpeername_exit (fd, sa, 1) — > 
clientlP := getIPAddress (sa) 

/ * Access limited to certain system calls before user login. */ 

3. ( ! setreuid())*;ftpInitBadCall() — >■ termO 

/ * Access limited to certain other set of system calls after user login is completed. */ 

4. setreuidO ; Euiy () * ; ftpAccessBadCallO — >■ termO 

/* Userid must be set to that of the logged in user before exec. */ 

5. ( ! setuid(loggedUser) ) * ; execve — >■ termO 

/ * Resetting userid to 0 is permitted only for executing a small subset of system calls. */ 

6. setreuidCr ,0) ; ftpPrivilegedCalls* ; ! (setreuidCrl , loggedUser) 

II setuid(loggedUser) I I ftpPrivCalls) — >■ termO 

/* A file opened with root privilege is explicitly closed, or has close-on-exec flag set. */ 

7. (open_exit (f , fl, md, f d) I geteuid()=0) ; ( ! close (f d) ) * ; 

(execve I ! closeOnExec(fd) ) — >■ termO 

8. connect (s, sa) I ( (getIPAddress (sa) != clientlP) 

&& (getPort(sa) 0 ftpAccessedSvcs) ) termO 



Fig. 3. A (partial) specification for f tpd. 



This specification was developed using the principle of least privilege, without paying 
any attention to previously known attacks on ftpd. It is interesting to note that in spite 
of this, the partial model would In fact detect known attacks such as FTP bounce (CERT 
advisory CA-97.27), FTP Trojan Horse (CERT advisory CA-94.07) and race conditions 
in signal handling (CERT advisory CA-97.16). None of these attacks would be detected 
by the generic specification alone. 



3.4 Step 4: Customizing Specifications for an OS/Site 

In this step, we do the following: 

- Define system calls that fall under each group determined in Step 1 . We will also 
define system calls that are included in any groups that may have been defined 
explicitly for the purpose of writing an application-specific specification, e.g., the 
ftpPrivilegedC alls in the ETP specifications. 

- Refine the lists of files that are used in generic or application-specific specifica- 
tions. We perform this refinement by running the program and logging the list 
of files it accesses using the specifications. For instance, the programs on So- 
laris write into the /devices/pseudo/pts* files, whereas on Linux they do not. 
So /devices/pseudo/pts* is removed from the fileWriteList mentioned in Step 
1 . 

- Add site specific security policies. These are policies which restrict certain policies 
that are normally allowed by an application. For instance, users of anonymous ftp 
may not be allowed to write into the "ftp directory. 
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3.5 Step 5: Adding Misuse Rules to Specifications 

Certain attacks can be detected only based on knowledge about specific attack behavior. 
For instance, even a small number of login failures using the user name guest usually 
indicates an attack. In contrast, small number of failures are not that unusual with other 
user names, as users frequently mistype or forget their passwords. Knowing that an 
attacker is likely to try cracking the guest account is thus crucial for detecting such 
attacks. Note that this knowledge pertains to attacker behavior, rather than the behavior 
of the program itself. As such, it is hard to develop (normal) behavior specifications 
that can accurately detect this attack. However, it is possible to encode this knowledge 
about attacker behavior as misuse rules that are designed to capture typical actions of 
an attacker. With misuse rules in place, we can detect such attacks accurately. 

We note that our pattern language BMSL is well-suited for capturing normal as 
well as misuse rules. However, we note that reliance on such misuse rules should be 
minimized, as they need to be updated when new attack behaviors are discovered. 



4 Experimental Results 



In this section we discuss our experimental results obtained on the 1999 DARPA/Lincoln 
Laboratories offline evaluation [‘5||. We also briefly summarize the results we obtained 
in the 1999 DARPA/AFRL online evaluation. 

Lincoln Labs recorded program behavior data using the Basic Security Module 
(BSM) of Solaris, which produces an audit log containing data in BSM format. We used 
BSM audit records that corresponded to system calls. Each such record provides system 
call information (such as its name, a subset of arguments and return value), as well as 
process-related information (such as process id, userid and groupid of the process). In 
addition, specific records contain source and destination IP-address and port information. 
The BSM audit records are well documented in j^. 

In order to use the BSM data, we had to develop a runtime environment that would 
parse the BSM audit logs, and feed the events Into the detection engine component 
shown in Figure 0 Development of such an RTE had not been undertaken until the end 
of year 2000. Therefore, our experiments were conducted after Lincoln Labs had pub- 
lished the results of 1999 evaluation, including information about the attacks contained 
in the evaluation data. This factor enabled us to focus our initial specification develop- 
ment effort on programs involved in attacks, as opposed to all programs. Specifically, 
we developed specifications for 13 programs; in.ftpd, in.telnetd, eject, ffbconfig, 
fdf ormat, ps, cat, cp, su, netstat, mail, crontab and login. All Other programs were 
monitored using generic specifications with default values for various file lists. Note, 
however, that several programs such as init, and several daemons such as crond were 
not audited, and hence could not be monitored. We were planning to expand the number 
of program-specific specifications to include more setuid programs, but found that the 
above list already included over 50% of the setuid programs present in the evaluation 
data, with or without attacks on them. The complete list of specifications developed for 
this experiment can be found at Q. 
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4.1 Specification Development 

The specifications were developed using the five step process of Section^ 

- Step 1: We developed generic specifications shown in Figure El 

- Step 2: We refined the generic specification for two important program groups, 
namely, setuid programs and daemon processes. 

- Step 3: We developed application-specific specifications for FTP and telnet servers. 
(Actually, our work was one of porting specifications for these programs that were 
originally written for a Linux environment.) 

- Step 4: We added site-specific security policies to these specifications. One such 
policy was stated explicitly by Lincoln Labs; that files in the directory secret should 
not be accessed using cp and cat. There were also some implicit policies, e.g., 
anonymous ftp users should not write files into the directory 'ftp, nor should they 
read or write files in hidden directories. In step 4, we also populated various file 
list parameters of the generic and application-specific specifications for the setuid 
programs, daemons and network servers. Finally, we defined a default value for the 
file lists so that the generic specification can be used with all programs that did not 
have a customized specification. 

- Step 5; HTTPtunnel and guest attacks in the BSM data could not be characterized 
in terms of the normal behaviors of programs. We thus added misuse rules to the 
specifications to detect these attacks. 

4.2 Results 

According to the result data provided by Lincoln Labs, 1 1 distinct attacks were repeated 
to generate a total of 28 attack instances. It turned out that two of these attacks were not 
actually present in the data due to corruption of the BSM files during the times when 
these two attack instances were carried out. One other instance (namely, the setup phase 
of the HTTPtunnel attack) was not visible in the BSM data. Offsetting these, there were 5 
additional instances of the attack phase of the HTTPtunnel attack. Thus, the total number 
of attacks present in the data was 30. 

Table 0I summarizes the 11 attack types and 30 instances of these attacks that were 
present in the data. The table specifies the number of instances of the attack in the data and 
the number of instances detected using the specifications developed till step 4 and step 5. 
Most attacks were discovered at the end of step 4. A few attacks could not be legitimately 
characterized as deviations from normal behavior. In these cases, we developed misuse 
specifications to detect the attacks (step 5 of the specification development effort). At 
this point, all of the attacks could be detected. The last row of the table specifies the total 
number of instance of all the attacks and the percentage detected after step 4 and step 5 . 

The percentages shown in the figure refer to the percentage of attack types detected, 
rather than attack instances. For every attack type, all instances were identical, so it makes 
more sense to count the fraction of attack types detected rather than attack instances. 

Most of the attacks were relatively simple, and were detected without any problem 
by our system. This was in spite of the fact that little effort had been put into developing 
program-specific behavioral specifications. In the next subsection, we discuss some of 
the noteworthy attacks in the data, and comment on how they were detected by our 
system. 
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Attack Name 


Number of instances 


Percent instances detected] 


after Step 4 


after Step 5 


Fdformat 


3 


100% 


100% 


Ffbconfig 


1 


100% 


100% 


Eject 


1 


100% 


100% 


Secret 


4 


100% 


100% 


Ps 


4 


100% 


100% 


Ftp write 


2 


100% 


100% 


Warez master 


1 


100% 


100% 


Warez client 


2 


100% 


100% 


Guess telnet 


3 


100% 


100% 


HTTP tunnel 


7 


0% 


100% 


Guest 


2 


0% 


100% 


Total 


30 


82% 


100% 



Fig. 4. Attacks detected in BSM data 



4.3 Description of Selected Attacks and Their Detection 

Buffer overflows. There were four buffer overflow attacks on eject, fdformat, 
ffbconf ig and ps programs. The attacks on the first three programs exploited a buffer 
overflow condition to execute a shell with root privileges. The specification we used to 
monitor setuid to wot programs could easily detect these attacks by detecting oversized 
arguments and the execution of a shell. In addition, a violation was reported when the 
buffer overflow attack resulted in execution of an unexpected program (shell). 

The ps attack was significantly more complex than the other three buffer overflow 
attacks. For one thing, it used a buffer overflow in the static area, rather than the more 
common stack buffer overflow. Second, it used a chmod system call to effect damage, 
rather than the more common execve of a shell program. Nevertheless, chmod operation 
is itself unusual, and it is not permitted by our generic specification (except on certain 
files). Thus, detection of this attack was straightforward. 

Site specific property. A policy indicating that all files in the directory 
/export /home/secret/ are secret and cannot be moved out of the directory by programs 
such as cp and cat was published by Lincoln labs. By adding this policy in step 4, we 
were able to detect violations of this policy and hence flag these attacks. 

Ftp-write attack. The ftp-write attack is a remote to local user attack that takes ad- 
vantage of a common anonymous ftp misconfiguration. The "ftp directory and its 
subdirectories should not be owned by the ftp account or be in the same group as the 
ftp account. If any of these directories are owned by ftp or are in the same group as the 
ftp account and are not write protected, an intruder will be able to add files (such as a 
. rhosts file) and eventually gain local access to the system. We could detect this attack 
easily due to the site-specific policy that no file could be written in "ftp directory. 

Warez attacks. During this attack, a warezmaster logs into an anonymous FTP site and 
creates a file or a hidden directory. In warezclient attack, the file previously downloaded 
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by the warezmaster is uploaded. This attack could be easily captured by the specifications 
which encoded the site-specific policy of disallowing any writes to the "ftp directory. 

Guess Telnet. This is similar to a dictionary attack, where the attacker makes repeated 
attempts to login by guessing the password. The behavioral specification for telnetd, 
had a specification which limited the number of login attempts and flagged an attack, 
when the number exceeded 3. 

Guest. The guest attack is not amenable to detection using a specification of normal 
behavior because of the fact that the detection of the attack requires the knowledge that at- 
tackers commonly try the user /password pairs of guest/guest and guest/anonymous. 
The attacks simulated by Lincoln Labs involve only two such attempts, with the sec- 
ond attempt ending in a successful login. We therefore encoded this knowledge about 
attacker behavior in our specifications, and were then able to detect all instances of the 
guest attack. Note that a related attack, namely the guess telnet attack, can be detected 
by a positive specification, as discussed earlier. To detect the guest attack, we used the 
system call chdir to directory /export /home/guest as the marker to indicate a guest 
login. After 2 or more login attempts a chdir to the file /export /home/guest was flagged 
as an attack. 

HTTPtunnel. The HTTP tunnel attack is the most questionable of all attacks. This 
attack involves a legitimate system user installing a program that periodically connects 
to a remote attacker site, using a connection initiated by the UNIX cron daemon and sends 
confidential information to the site. As per the configuration of the victim system, the user 
(i.e., attacker) in this case was allowed to add cron jobs, and was also allowed to connect 
to remote sites. Since legitimate user may have used these facilities to periodically 
download legitimate information such as news and stocks, and there is no easy way to rule 
out these as the reasons for installation of the HTTP tunnel software, we could not develop 
a normal behavioral specification. Therefore, we developed a misuse specification that 
captures the periodic invocation of a program by cron such that this invocation results 
in a connection to a remote server. 

Periodic invocation of a program by cron can be identified by the marker system call 
fork. However, since crond was not audited, the fork system call made by crond was 
not present in the BSM data. But all subsequent system calls made by the child process 
of crond were present. However, there is no identification of where this child process 
came from, which makes it impossible in our setting, to associate any specifications 
with the child process. To work around this problem, we observed that the children of 
crond execute a sequence of system calls not seen elsewhere. We used this sequence as 
a marker, and made it a part of the generic specification that would be used to monitor 
all processes. Our misuse specification for HTTPtunnel is shown in FigureEl Function 
raiseFlag sets a global flag to 1, as soon as the cron process starts. The cron process 
then forks and execs. In rule 2, setFlag sets the global flag to 2 after the f orkO . When 
the cron job initiates a connection, rule 3 flags an attack. 

The setup phase of the HTTPtunnel attack was not visible in the BSM data, since 
some of the data that is crucial for the setup phase was not recorded in the BSM logs. In 
particular, the setup phase involves installing a new crontab file that contains an entry 
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for period invocation of the HTTPtunnel attack, but the file contents are not recorded in 
the BSM audit logs. 



/* To run a cron job, crond forks children which immediately execute the following system 
call sequence. */ 

1 . openCal , a2 , a3) ; ioctl(a4, a5,a6) ; close (a6) ; setgroups (a7 , a8) ; 
setgroups (a7 , a8) ; open(a9 ,alO , all) ; ioctl(al2 , al3, a4) ; 
close (a6) ; setgroups (al4, al5) ; open(al7,al8 , al9) ; 

f cntl(a20 , a21 ,a22) ; close (a6) ; close (a6) ; creat (a23, a24) ; 
f cntl(a20 , a21 ,a22) ; close (a6) ; f cntl(a20 , a21 , a22) ; close (a6) ; 
close (a6) ; chdir (a30) ; close (a6) ; close (a6) ; 
execve (a25 , a26 , a27) — >■ setFlag(l); 

/ * The child then forks and execve ’s the process it has to run. */ 

2. f orkO I checkFlag() = l — >■ setFlag(2) ; 

/* If the process spawned by crond connects to a remote host we log an attack. */ 

3. connect (al , a2 , a3) I checkFlag()=2 — >■ log( ‘ ‘ illegal connect’’) 



Fig. 5. Specifications to detect connection of a cron job to a remote host. 



False Alarms. No false alarms were reported by our method on the BSM data. This 
result strengthens our claim that specification-based approaches produce very few false 
positives. It also shows that the test data did not particularly stress our IDS. When tested 
against a more sophisticated or comprehensive attack data, our system would likely lead 
to a higher rate of false positives. 



5 Discussion 

5.1 Effectiveness of Our Approach 

Without including the misuse specifications, we could detect 80% of the attacks with 
0% false positives. After including the misuse specifications we could detect 100% of all 
attacks with 0% false positives. While this result would surely not hold against a more 
sophisticated attack data, it does demonstrate the high “signal-to-noise ratio” that can 
be achieved by our specification-based approach. 

It might be argued that our results would not have been as good if we had participated 
in the evaluation, since we would not have known all of the attack instances present in 
the data. We point out, however, that we achieved similar results in the 1999 online 
evaluation, where we entered the evaluation with no knowledge about the attacks that 
they were going to subject our system to. We did not even have the ability to rerun the 
attacks if we were to encounter any difficulties or bugs in our IDS. But this result is not 
without its own caveats: the online evaluation involved only three distinct attack types. 
The attack types, however, were significantly more complex than the offline evaluation, 
as they were designed to stress our IDS. 
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5.2 Development Effort 

We found that very general specifications seem to be sufficient for detecting a majority 
of the attacks. In fact, many attacks produce violations of multiple rules, thus suggesting 
that the attacks may be detectable with even less effort in specification development than 
we expended. The initial development of generic specifications, which was undertaken 
for the AFRL online evaluation, was about 12 man hours and it resulted in 9 rules and 12 
lines of code in BMSL. Behavioral specifications for applications such as ftpd took a 
longer time. In particular for ftpd we developed 14 rules which were 18 lines of code 
in BMSL. However as we mentioned earlier, the sophistication of this specification was 
hardly necessary for detecting the attacks in the data. Thus, typical application- specific 
specifications need not be that exhaustive. 

As described earlier in Section Em the specifications for setuid to wot programs 
required a few modifications to the generic specification. It took us about 6 man hours 
to refine and customize the specifications. Here too, a higher degree of effort is needed 
in the beginning, i.e., the development of specifications for the first one or two setuid 
programs. Most of the specifications developed were not dependent on any particular im- 
plementation of UNIX operating system, so the effort required for subsequent programs 
was only in making minor changes in the file and process lists. These changes took as low 
as 10 minutes per program. Projecting from these results we can state that customizing 
specifications for new programs will not involve much effort. In fact, noting that there 
are only several tens of daemon programs and setuid programs, and only a handful of 
server programs, the total amount of effort required for specification development is in 
the range of a few tens of man hours, which we consider to be quite acceptable. 

Another way to look at the development effort is to compare the specification de- 
velopment effort with that needed for training anomaly detection systems. We note that 
production of training data (by a human) for anomaly detection systems is resource- 
intensive. It is very important to ensure that the training data encompasses almost all 
legitimate behaviors, which is difficult, and typically requires manual intervention on a 
program by program basis. Moreover, it may be necessary to cross check and manually 
verify that the anomaly detector did not end up learning artifacts in the training data, as 
opposed to learning features that were pertinent to the normal operation of a program. 
In addition, trained data is usually specific to a particular installation of an operating 
system. Considering these factors, we believe that it would be hard to do better than few 
tens of man hours for training with respect to several tens of programs. 

5.3 Portability 

We had initially developed our specifications for Linux operating system. However to 
test attacks in BSM data we had to port them to Solaris. We found that except for Step 
5, the specifications did not require any modifications. The effort required for step 5 
was also modest: of the order of 10 to 30 minutes per program. Here again, the effort 
required for the first one or two programs was higher, of the order of one or two hours. 
Subsequent programs took much lesser effort, of the order of 10 minutes per program. 

We point out that accurate measurement of development effort is very hard for the 
following reasons. First, the development effort will be reduced if we followed the 
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methodology outlined earlier in this paper. However, this methodology evolved as a 
result of our experiences, and hence, our specification development efforts were higher 
towards the early part of our experiments. Second, our ability to develop and debug 
specifications improves gradually with experience. Thus, a task that took us days to 
complete initially would now take hours. 



5.4 Novel Attacks and False Positive Rates 

As shown in Table 01 over 80% of the attacks could be detected without encoding any 
attack-specific information into the specifications. Viewed differently, all of these attacks 
are “unknown” to our system. The relatively high detection rate supports our claim that 
specification-based approaches are good at detecting unknown attacks. The low rate of 
false alarms supports our claim that specification based approaches can detect novel 
attacks without having to sacrifice on the false alarm front. 

Perhaps the notion of “unknown” attacks is better defined in the context of the online 
evaluation, where we really had no knowledge of the attacks that our system was going 
to be subjected to. In the online evaluation, we did not encode any misuse rules, and 
hence all detections were based on normal behavior specifications. In this context, our 
system detected all of the three attacks launched during this evaluation, once again with 
zero false alarms. 

We emphasize once again that neither the offline nor the online evaluation stressed 
the capabilities of our IDS. If they had, we would have an experimental basis to compare 
the ability of the specification-based approach for detecting new attacks as compared 
with anomaly detection approaches. Nevertheless, we wish to point out some differences, 
based on the way the two approaches operate. 

- A learning-based approach learns a subset of all legitimate behaviors of a program - 
this subset corresponds to those behaviors that were actually exhibited by a program 
during training. To eliminate false-positives, we must ensure that all legitimate be- 
haviors are exercised during training. In practice, this turns out to be the problem of 
ensuring that all program paths are exercised. As is well-known in software testing, 
achieving 100% coverage of all program paths is essentially impossible due to the 
astronomical number of paths in a program. As such, some rarely traversed paths 
are never learnt, leading to a fair number of false positives. 

A specification is aimed at capturing a superset of possible behaviors of a program. 
As such, there is no inherent reason to have false positives, except due to specification 
errors. 

- The superset-subset argument above also indicates that there may be some behaviors 
that are outside of the legitimate behaviors of a program, but within the superset 
captured by a specification. Exploits that involve such behaviors will be missed 
by a specification-based approach, while they can be captured by a learning based 
approach. 

- There exist a significant number of attacks that can detected by specification based 
approaches that are difficult or impossible to detect using anomaly detection. This 
occurs for two main reasons: 
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• For certain latent errors, the learning-based approach essentially learns that ex- 
ecution of a security-relevant error is normal. Viewed alternatively, exploitation 
of the error to inflict intrusion does not lead to any change in the behavior of the 
program containing the error. This class of errors is fairly extensive in scope, 
and includes the following; 

* race conditions in file access 

* opening files without appropriate checks 

* leaving temporary files containing critical information 

A specification can constrain the program execution so that it does not take 
actions that leave opportunities for exploitation. We routinely add specifica- 
tions that protect against the above kinds of errors to most programs. (We note, 
however, that none of these types of attacks were present in the 1999 offline 
evaluation, although they are reported frequently enough by CERT (!•) 

• Existing anomaly detection approaches based on system calls generally ignore 
system call argument values. This makes it difficult to detect many attacks where 
normal behavior is distinguishable from attacks only in terms of such argument 
values. Examples of such attacks include: 

* executing /bin/sh instead of Is 

* writing to /etc/passwd instead of some other file 

Based on our analysis of fhe attacks reported by CERT |3|, over 20% of the attacks 
reported in the period 1993 to 1998 fall in this category of attacks not detectable by 
anomaly detectors. 

- Anomaly detectors typically need to be trained/tuned for each host/site. In contrast, 
our specifications seem to dependent only on an operating system distribution, rarely 
requiring any customization for individual hosts/sites. 



6 Conclusions 

1 . Our specification-based approach is very effective. It was able to detect 80% of 
the attacks with only positive behavior specifications. Since these specifications 
did not incorporate any knowledge about attacks or attacker behavior, this experi- 
ment demonstrates the effectiveness of the specification-based approaches against 
unknown attacks. 

2. Very general specifications seem to be sufficient for detecting a majority of the 
attacks. In fact, many attacks produce violations of multiple rules, thus suggesting 
that the attacks may be detectable with even less effort in specification development 
than what we put into it. 

3 . Users of our approach can trade increased specification development efforts against 
decreased probability of successful attacks. This is borne by the fact that by investing 
some additional effort, we were able to detect all of the attacks included in the BSM 
data. 

4. By combining specifications of legitimate program behaviors with some misuse 
specifications, 100% detection rate could be achieved with 0% false positive rates. 
While this result would likely not hold against a more sophisticated attack data, 
it does demonstrate the high “signal-to-noise ratio” that can be achieved by our 
specification-based approach. 
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5. Our specification-based approach is typically able to provide additional attack re- 
lated information that can be used to pinpoint the attack, e.g., execution of a disal- 
lowed program, access to certain privileged operations, access to disallowed files, 
etc. 
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Abstract. This paper presents a new approach to run-time security 
monitoring that can detect system abnormalities including attacks, 
faults, or operational errors. The approach. System Health and Intru- 
sion Monitoring (SHIM), employs a hierarchy of constraints to describe 
correct operation of a system at various levels of abstraction. The con- 
straints capture static behavior, dynamic behavior, and time-critical be- 
havior of a system. A system in execution will be monitored for violation 
of the constraints, which may indicate potential security problems in the 
system. SHIM is based on specification-based intrusion detection, but it 
attempts to provide a systematic framework for developing the specifi- 
cations/constraints. SHIM does not detect directly the intrusive actions 
in an attack, but their manifestations as violations of constraints. In this 
paper, we describe the constraint model and the methodology for de- 
veloping the constraints. In addition, we present preliminary results on 
the constraints developed for host programs and network protocols. By 
bounding the behavior of various system components at different levels 
of abstraction, SHIM has a high chance of detecting different types of 
attacks and their variants. 



1 Introduction 

In a large mission-critical system, an advanced monitoring system that can con- 
tinuously assess the health and status of a system is highly desirable. Such 
monitoring system should provide operators with prompt alerts on system ab- 
normalities (e.g., intrusions, faults, or operator errors) that could lead to system 
failures so that appropriate actions can be performed to avert emerging prob- 
lems. This paper presents an approach to health monitoring of computer systems 
focusing on security aspects. The approach employs a hierarchy of constraints 
that models the valid (or correct) behavior of a system at various levels of ab- 
straction. The approach can detect intrusions or errors that could cause security 
failures. 

* This research is supported by Defense Advanced Research Project Agency (DARPA) 
under contract F30602-00-C-0210. 
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Traditionally, automatic detection of intrusions is done following one of two 
methods. First, intrusions can be recognized by looking for features that match 
a pattern associated with malicious behavior m One collects, in advance, 
the signatures of suspicious events and monitors for them. While this method 
can detect attacks with fairly low false alarms, it has the disadvantage of not 
being able to handle previously unseen types of attacks. In the second method, 
a statistical profile of normal behavior is accumulated over time. Then, alerts 
are generated for every unusual event not consistent with the profile jHj. While 
this method can potentially detect new and previously unseen attacks, it triggers 
indiscriminately on any new behavior, malicious or not, resulting in unacceptably 
high false alarm rates 

A third approach is a specification-based approach in which the correct, al- 
lowed behavior of a system is specified and events not matching the specification 
generate an alert. New attacks will be detected, and unusual, but perfectly cor- 
rect behavior will not generate spurious false alarms. Previously, specification- 
based techniques mostly focus on monitoring of programs IHyifTj . 

Our approach extends existing specification-based techniques to constrain 
behavior of various components in a distributed system. In particular, we create 
constraints at various levels of abstraction and on different entities in a system, 
including programs, protocols, hosts, system services, network services, as well 
as the whole enclave. The constraints capture static behavior, dynamic behav- 
ior, and time-critical behavior of the components. The constraints are devel- 
oped systematically from a high-level system policy, system semantics, security 
principles, historical behavior of the system, and generic knowledge of intru- 
sions/vulnerabilities. The constraints will be checked at run time for unexpected 
behavior. The constraints also provide hints on the possible consequences (e.g., 
object damaged) if the constraints are violated. Our approach does not detect 
directly the intrusive actions in an attack, but it detects their manifestations 
as violations of constraints. Just as hardware faults or software bugs manifest 
themselves as errors in applications or operating systems, intrusive actions of- 
ten cause security violations in the forms of invalid uses or changes to critical 
data, invalid program behavior, invalid protocol transactions, and invalid re- 
source usage. By imposing constraints on the system behavior at various levels 
of abstraction, SHIM has a high chance of detecting attacks. 

In Section 2, we provide some motivation of our approach by describing some 
attacks and their possible variants. It also provides some insight into accurate 
detection of these attacks. Section 3 describes the constraint model and the 
methodology for developing the constraints. Next, we present some preliminary 
results on the developed constraints in Section 4. Last, we provide conclusions 
and suggest possible future work in Section 5. 



2 Detecting the Variants and the Unknown 

One of the most difficult problems in intrusion detection is accurate detection 
of all possible variations of known attacks and new types of attacks. Given a 
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specific attack scenario or an attack script, it is relatively easy to develop the 
signatures/rules that can catch the particular attack. While the rules can detect 
novice attackers who run the script directly, experienced attackers usually twist 
the steps to evade detection by intrusion detection systems. In this section, we 
discuss several existing attacks and their possible variants. 



2.1 Attacks on FTP Servers 

The first attack is related to a vulnerability in the wu-ftp 2.42 FTP daemon |S|. 
In this attack, the intruder establishes a connection to a machine that has the 
specific FTP daemon running and sends a carefully crafted message containing 
the attacker’s code to overflow a buffer, causing the daemon to execute a shell 
(/bin/sh) for the attacker. 

This attack is observable at different levels. At the network level, there are 
network packets that being transmitted from the attacking machine to the victim 
machine. At the host level, one could observe one or more read() system calls 
that read the attacker’s message. Also, one could observe some change in the 
behavior of the FTP daemon after it has been tricked to execute the injected 
code. 

One could easily detect such attack by monitoring the network. Shown below 
are the rules for SNORT [9] for detecting such attack. Basically, the rules look 
for the sequence of bytes (highlighted) in the network packets associated with 
the specified connection. 



alert tcp ! $HOME JSTET any -> $HOMEJSTET 21 
(msg : "OVERFLOW-FTP-x861inux-adm" ; flags : PA; content : " | 

31 cO 31 db bO 17 cd 80 31 cO bO 17 cd 80|";) 

alert udp ! $HOME JSTET any -> $HOME JSTET any 

(msg: "IDS181 - OVERFLOW-NOOP-X86" ; content :" | 9090 9090 

9090 9090 9090 9090 9090 9090|";) 

alert tcp ! $HOME JSTET any -> $HOIME JSTET any 

(msg: " OVERFLOW- LinuxCommonTCP" ; flags : PA; content : " | 90 

90 90 e8 cO ff ff f f | /bin/sh" ; ) 



The first signature is crafted to detect the use of a publicized exploit script 
(ADMwuftp.c) for the vulnerability. It looks for a specific byte sequence (Hex- 
code 31 cO ...) that is presented in the message sent by the exploit script to 
fill up the buffer in the FTP daemon. The second signature looks for a pat- 
tern (a sequence of 0x90 characters that represent the NOP operations for the 
Intel CPUs) that usually presents in a buffer-overflow exploitation. The third 
signature looks for a common character sequence (for executing a shell such as 
/bin/sh) in the code injected by attackers. 
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It is very easy to create stealthy attacks to escape detection by these SNORT 
rules. Several techniques, such as changing the order of the instructions, using 
different instructions for the same objective, using different registers in instruc- 
tions, or even encrypting part of the message, can be used to twist the attack 
m- It is very difficult to write SNORT rules to detect all possible attack vari- 
ants that exploit the vulnerability. Nevertheless, the chance of detection could be 
improved by monitoring the activity at the network level, the host level, and the 
application level, as advocated by our approach. For example, the constraints 
presented in Section 4 can detect different attacks to the FTP daemon using 
host audit trails. 



2.2 Attacks on Privileged Programs 

This subsection describes a vulnerability in the 4.2 BSD UNIX mail program 
located in the /bin directory (hereafter binmail) and several related intrusions 
that exploit this and similar vulnerabilities [Q- Binmail is the back-end mailer 
program in the mail subsystem used for delivery of mail messages. To deliver a 
message to a user, binmail appends the message directly to a user’s mail-box file, 
located in the mail spool directory. After that, binmail changes the ownership 
of the mail-box file to the user to ensure that the file is accessible by the user. 



Table 1. An Example of an Intrusion Expoliting /bin/mail. 



Step 


Command 


Comment 


1. 


cp /bin/csh /var/spool/mail/root 


Assumes no root mail files 


2. 


chmod 4755 /var/spool/mail/root 


Mail root with the empty file 


3. 


touch X 


Create empty file 


4. 


mail root < x 




5. 


/ var /spool/ mail /root 


Execute setuid-to-root shell 


6. 


root# 


Prompt of root shell 



Table 1 summarizes the steps of an intrusion that exploits this property of 
binmail to illegally acquire root privileges. In step I, the attacker creates a copy 
of csh{l) and names it after root’s mail-box file /var/spool/mail/rool0. In step 
2, the attacker enables the setuid bit of the fake mail-box file. In steps 3 and 4, 
the attacker creates and sends a message to root using the mail utility. When 
the mail subsystem delivers the message, it changes the owner of the file to root, 
resulting in a setuid root shell that is publicly executable. 

^ In general, the mail-box of a user is the file named “/var/spool/mail/<username>” , 
which should be owned by “username” and readable and writeable only by the 
owner. The attacker can do that only when there is no unread mail of root so that 
the mail-box file of root does not exist. 
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It is straightforward to encode this sequence of operations as expert rules in 
a rule-based misuse detection system. However, it is not trivial to identify all 
variants of this intrusion. 

Table 2 and Table 3 present variations of the intrusion, both of which create 
a counterfeit root’s mail-box file that is publicly executable and has the setuid 
bit on before the mail utility is invoked to deliver a mail message to root. In 
Table 2, the attacker creates a copy of csh and names it after root’s mailbox file 
(/var/spool/mail/root) in step 1. In step 2, the attacker creates an alias of the 
mail-box file by making a symbolic link pointing to the file. In step 3, instead 
of changing the permission mode of the counterfeit mail-box file directly, the 
attacker invokes chmod with the symbolic link as parameters, in effect changing 
the permission mode of the mail-box file to setuid and publicly executable. In 
step 4, the attacker invokes mail and interactively keys in an empty message. 



Table 2. First Variant of an Intrusion Exploiting /bin/mail. 



Step 


Command 


Comment 


1. 


cp /bin/csh /varr/spool/mail/root 


Create a counterfeit root’s mail file 


2. 


In -s /tmp/mroot /var/spool/mail/root 


Create an alias of the mail file 


3. 


chmod 4777 /tmp/mroot 


Make the mail file setuid 


4. 


mail root < x 


Mail root and give input non- 
interactively 


5. 


/var / spool / mail/root 


Execute setuid-to-root shell 


6. 


root# 


Prompt of root shell 



In Table 3, the attacker first creates a temporary copy of csh, /var/spool/ 
mail/tmp, in the mailbox directory. In step 2, the attacker enables the setuid 
bit of the copy of csh and makes it publicly executable. In step 3, the attacker 
renames the temporary copy to the mail-box file of root, in effect creating a 
counterfeit mail-box file of root. Then the attacker does not send mail to root, 
but waits until another user sends mail to root. After a user sends mail to root 
using mail, the attacker executes the mail-box file to obtain root accesses. 

It is not straightforward to identify all possible sequences of actions that 
exploit a given vulnerability. One cannot just examine one attack scenario and 
extract the steps in the scenario to form the signature. For example, the signature 
extracted from the first attack could consist of three key actions: 1) the attacker 
creates a counterfeit mail-box file of root, 2) the attacker changes the permission 
of the counterfeit file, and 3) the attacker changes the ownership of the mail- 
box file. However, such signature will fail to detect the second variation of the 
attack. One needs to know the intrinsic problem behind the vulnerability. The 
flaw presented in this section allow the system to move into a compromised 
state if the mail-box file of root is setuid and publicly executable when binmail 
is run, or more exactly, when binmail performs the chown call to change the 
ownership of root’s mail-box file. Therefore, in order to detect exploitations of 
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Table 3. Second Variant of an Intrusion Exploiting /bin/mail. 



Step 


Command 


Comment 


1. 


cp /bin/csh /var/spool/mail/tmp 


Create a temporary copy of C shell 


2. 


chmod 4777 /var/spool/mail/tmp 


Make the copy setuid 


3. 


mv /var/spool/mail/tmp 
/var / spool / mail/root 


Rename the temporary copy 


4. 


other% mail root 


Another user send mail to root 


5. 


/var /spool/ mail /root 


Execute setuid-to-root shell 


6. 


root# 


Prompt of root shell 



this vulnerability, we need to 1) detect the actions by the attacker that result in 
a counterfeit mail-box file of root that is setuid and publicly executable, and 2) 
detect when binmail changes the ownership of the file /var/spool/mail/root to 
root while the mode of the file is setuid and publicly executable. 

2.3 Attacks on the Address Resolution Protocol (ARP) 

At the application level, computers communicating over the Internet use IP ad- 
dressing. Physically, however, computers communicate using devices with hard- 
wired hardware addresses. The ARP protocol allows one to map an application- 
level IP address into the physical address (e.g., Ethernet address) that the hard- 
ware needs to send the electronic signal. Applications using IP address infor- 
mation as a basis for trust, then, can be fooled into communicating with an 
untrusted machine if this mapping mechanism can be corrupted. 

A machine attempting to connect to another will broadcast an ARP address 
request to all other machines on its network. The message is of the form 

Who-has <destination IP-address> Tell <source 
hardware - addr e s s > 

The remote host with the requested destination IP address will reply with his 
hardware address to the specific machine making the query. The reply looks like 

<destination IP-address> is-at <destination 
hardware - addr e s s > 

Once a machine’s query has been answered it will typically keep a copy of the 
mapping in its local ARP cache, alleviating the need to continually query for 
each message. Entries in the cache will timeout after a specified time interval 
after which a remote machine will need to be queried again for further com- 
munication. In this manner, a network of computers automatically handles the 
physical communications of applications using IP addressing, even when ma- 
chines leave or join the domain. Since the ARP protocol is designed with the 
assumption that all the hosts on the physical network are all well behaved, a 
malicious host on the network could fool other hosts into believing a wrong IP to 
physical address mapping. We have identified four different types of ARP cache 
poisoning. 
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1. Unsolicited response. Some operating systems blindly accept ARP replies 
whether or not they have sent a previous request. Forging a fake response 
message poisons that machines ARP cache. 

2. Malformed request. Oftentimes, a third party machine will cache the 
information contained in a third party broadcast request even though it is 
not involved in the protocol transaction. Sending requests with fake source 
information poisons these machines cache. 

3. Bogus response. Attacker waits to see a request on the network and ex- 
ploits the race condition vulnerability by replying first with his faked map- 
ping. 

4. Both fake request and bogus response. Attacker fakes both the re- 
quest and response to poison those machines implementing a solution to the 
unsolicited malformed request and unsolicited response problem. 

In Section 4, we present example constraints that can detect these attacks. 

3 Constraint Model 

The set of constraints required for monitoring the health of a distributed system 
varies depending on the site-specific security policy, configuration, and usage. 
Security officers should not have to spend a significant amount of time and 
effort to obtain the constraints for a specific system. We describe the constraint 
model that servers as a framework for developing the constraints for a distributed 
system. 

In this paper, there is an assumption that the distributed system under con- 
sideration exists within a bounded administrative domain. The term “enclave” is 
used to describe this bounded domain. An enclave refers to a network protected 
by a number of boundary controllers. Typically firewalls are used as boundary 
controllers. Our constraint model should be applicable to any bounded, dis- 
tributed system. Figure 1 depicts the constraint model, consisting of 3 different 
categories and 5 different constraint types. 



3.1 Constraint Categories 

The constraints for a distributed system may be viewed at different layers of 
abstraction. Each constraint category describes the constraints that can be made 
on a distributed system at various layers (See Figure 2). These three constraint 
categories are described below: 

1. Network- based constraints are based on the network traffic within the 
enclave. Network sensors are the primary source of audit data for evaluating 
the network-based constraints. 

2. Host-based constraints are based on the execution of privileged programs 
on the designated host. Operating Systems (OS) audit trails and OS kernel 
wrappers d are the primary source of audit data for evaluating the host- 
based constraints. 
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Fig. 1. Constraint Model. 



3. Application-based constraints are based on the execution of the desig- 
nated applications. OS audit trails, OS kernel wrappers, and application logs 
(e.g., syslog) may be used as a source of audit data. In addition, some ap- 
plications may be instrumented to provide additional audit data to evaluate 
the application-based constraints. 

3.2 Constraint Types 

For each system under consideration, constraints are specified for each constraint 
category. Individual constraints may be additionally classified as to a type of 
constraints. The five constraint types are described below: 

1. Access constraints are specified based on the objects (e.g., files and net- 
work ports) that users/programs are allowed to access. Access constraints are 
useful in detecting misbehaving programs that perform accesses to objects 
beyond what they need to access. 

2. Data constraints are concerned with the possible static state of the system. 
They define valid value ranges of specific file, data, or network messages. 

3. Operational constraints are specified base on the intended behavior of 
a privileged program, protocol, or application. Operational constraints are 
useful in detecting invalid protocol behavior. 

4. Temporal/Interaction constraints are specified based on the permitted 
interaction between processes and shared resources. This constraint type in- 
cludes atomicity, serialization, and mutual exclusion. Temporal/Interaction 
constraints are useful in detecting race condition attacks. 

5. Resource usage constraints are specified based on the memory, process 
tables, or network connections that a program or network service is allowed 
to use. Resource usage constraints are useful in detecting denial of service 
attacks. 
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3.3 Development of Constraints 

The constraint model provides a framework for development of the constraints 
for monitoring a distributed system. Obviously, the constraints required for dif- 
ferent environments will be different and often depend on the security policy, 
the security threats they face, and their configuration. We envision that a set 
of generic constraints of general interest can be developed, which can be chosen 
and tailored for specific systems. 

We describe the approach for developing constraints in this subsection. Con- 
straints should be specified for each of the three constraint categories: network, 
host, and application. Within each of the constraint categories, individual con- 
straints may be developed for the five constraint types: operational, tempo- 
ral/interaction, access, and resource usage. Depending upon the protocol or 
program under consideration, not all of the constraint types may apply. The 
constraints should closely model the valid behavior of the critical entity under 
consideration, so that any abnormal behavior involving the entity will likely 
cause a violation of the constraints. 



Security Policy 
Design Principles 
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Behavior 
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, Model 
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Constraints 
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Fig. 2. Process of Developing Generic Constraints. 



The process for developing the generic constraints is shown in Figure 2. The 
generic constraints are developed based on well-studied security policies and 
computer system design principles, historical behavior of the system, existing 
attacks, and vulnerability models [IPHY| . For example, some well-studied policies 
for integrity and availability, such as the Clark-Wilson model !ia, the Biba 
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integrity model m, and the Type Enforcement model m can be applied in 
the process. In addition, well-established design principles (e.g., least privileges, 
least common mechanisms, fail-safe defaults) for building secure systems jT^ 
are considered. These policies and principles have been applied in modeling, 
design, and implementation of secure systems to restrict their operations to 
achieve security goals and resist threats. However, existing systems do not take 
these principles seriously. Our rationale is that although these constraints are 
not directly enforced by existing systems, they can be monitored for violations 
so that corrective actions can be performed to avoid security failures. As the 
constraints are developed not just based on existing attacks, it can detect attacks 
that we have not seen before. 

4 Example Constraints and Implementation 

In this section we describe several interesting constraints developed based on 
the constraint model. In addition, we describe the implementation of these con- 
straints. The constraints restrict the behavior of various components in a com- 
puter system, including programs, protocols, and critical data. To be effective, 
one needs to identify the important components in a system to constrain, which 
depends on the policy that one wants to enforce and the security goal one wants 
to achieve. In this research, we initially focus on constraints for components that 
run with special privileges (e.g., root in Unix) and entities that are highly re- 
lated to these privileged components (e.g., protocols used by them). The goal is 
to protect the system from malicious normal user. 

4.1 Host-Based Constraints: Privileged Programs and Data 

We have developed constraints of different types for privileged programs. One 
useful type of constraints for privileged programs are access constraints, which 
restrict the files that can be accessed by a program. In general, one could iden- 
tify the rules for restricting the accesses of a program based on its functionality, 
usage, and the system security policy m For example, the following access con- 
straint of FTP expressed in English should be able detect the attack mentioned 
in Section 2.1 regardless how the attacker twists the message. 

1. Read files that are worldreadable 

2. Write files that are owned by the user 

3. Execute only /bin/ls, /bin/gzip, /bin/tar, /bin/compress 

4. Chmod or chown no files 

We are in the process of developing access constraints for all setuid root 
programs and root servers/daemons in a standard Linux system. Many example 
access constraints have been developed 00 ; we will not discuss them in depth 
here. 

Other interesting constraints for privileged programs include constraints on 
how it passes control to a user and how it deals with temporary files, written 
informally in English as follow: 



200 



C. Ko et al. 



A privileged process should discard all its privileges and capabilities before 
it gives control to a user, such as executing a shell-type program or a 
program created by a user - Cl. 

The temporary file for a program should be accessible only by the program 
execution and should be removed when the program exits - C2. 

In Unix, the first constraint would require a privileged process to reset the 
real and effective user ID to that of the user, as well as the real and effective 
group ID to that of the user. Also, it requires the privileged process to close any 
file descriptors on files that the user has no authority to access. Such constraint 
can detect any attacks that attempt to use the capability (e.g., a file descriptor 
for reading the shadow password file) left over by privileged processes jE]. The 
second constraint could detect attackers tampering with the temporary files used 
by privileged programs. 

In addition, we have developed data constraints on valid values of security- 
critical data. For example, the following constraints for the password file should 
alarm on any modification of password file that create a root account with no 
password. 

The password file /etc/passwd should be in the correct form and each user 
defined in the file should have a password - C3. 

So far, we have implemented an access constraint compiler for translating ac- 
cess constraint expressed in PE-Grammar p] into a C-I--I- object that can analyze 
the audit data for violation. The Generic Software Wrapper PU is employed to 
provide audit data for monitoring host-level activity. The kernel resident Generic 
Software Wrapper has proven to be an effective way for efficiently collecting au- 
dit data. The use of flexible audit mechanism such as wrapper is important. For 
example, we can use wrapper to provide information about the real and effec- 
tive user (group) ID of a process as well as the permission mode of all the files 
opened by a process before it executes a user program; such data is necessary 
for checking whether a privileged program violate the constraint Cl. 



4.2 Network-Based Constraints: Address Resolution Protocol 
(ARP) 

We have developed two constraints for the ARP protocol. In general, one can 
develop operational constraints to restrict how various messages in a protocol are 
exchanged as well as data constraints to confine values of data in the messages. 

The first constraint for ARP could be a data constraint requiring that the 
Ethernet-to-IP address mapping in any ARP message must be correct - the map- 
ping should agree with an authoritative database that keeps all Ethernet to IP 
mapping in the local area network. However, monitoring such constraint will 
require additional work in maintaining the authoritative database. In addition, 
it contradicts with one of the goal of ARP, which is to provide automatic sup- 
port for dynamic address mapping. Such constraint will work in a very static 
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environment in which no mobile machines are presented. However, it will not 
work well in a very dynamic networking environment. 

In addition, we have developed an operational constraint for the ARP proto- 
col. Figure 3 specifies the correct operational behavior of ARP protocol using a 
state transition diagram. From the initial state, an ARP request on the network 
asking for an IP address mapping moves the system to the “Reply _wait” state 
for that particular address. Additional address requests coming while in this 
state have no effect since it is perfectly valid for machines to resend the request 
if they weren’t answered in a timely fashion. After the response message is seen, 
the system moves to the “Cached” state. Finally, after the timeout, the system 
moves back to the initial state. 




Fig. 3. A Constraint for the ARP Protocol. 



We have implemented a simple network monitor for checking the ARP opera- 
tional constraint. The monitor is implemented as a pre-processor to the SNORT 
open source IDS. All ARP traffic on a local network is used to move the system 
through the series of states, keeping track of valid IP address to MAC address 
mappings. Due to the relatively small volume of ARP traffic in general, our sys- 
tem is easily able to handle the ARP traffic generated by the 50 machines in our 
monitored domain. 

Using the single specification for correct ARP behavior, the network moni- 
tor is able to identify all of these variants of the ARP cache poisoning attack 
described in Section 2.3. These all known methods of ARP cache poisoning 
attacks, spanning multiple versions and operating systems, are detectable as in- 
correct and, therefore disallowed ARP protocol transactions. There are, however, 
considerable false reports due to DHCP automatic allocation of IP addresses. 
To remove these false alarms, we are currently developing a specification for 
DHCP itself. This specification would not only monitor for misuse of the DHCP 
protocol, but DHCP specific transitions will feed into the ARP protocol specifi- 
cation, indicating that a particular ARP message is perfectly valid in the DHCP 
context . 




202 



C. Ko et al. 



4.3 Application Constraints 

This subsection describes an application constraints motivated by the following 
example. 

The program Joe is a user-friendly text editor originally written by Joseph 
Allen and currently maintained by the open source community. When started, 
the application loads a hidden configuration file called .joerc if it exists in the 
current working directory. The file .joerc may contain instructions for the text 
editor to execute arbitrary command. 

An malicious user can created a carefully crafted .joerc file in a world-writable 
directory. So that whenever a different user (e.g. root) edits a file in that world 
writable directory, the instruction specified in the .joerc file will be executed with 
the permissions of the person editing the file. The constraint C4 stated below 
can detect such misuse: 

An application should read only configuration files owned by the user whom 

it is running as - Cf. 

5 Conclusions and Future Work 

In this paper, we present an approach to real-time security monitoring of a 
distributed system using a hierarchy of constraints. The approach confines the 
behavior of system components at various levels of abstraction to increase the 
detection coverage. We discuss the constraint model and provide several example 
constraints for privileged programs, critical data, and the ARP protocol. The 
constraints are implemented as a host-based analyzer that examines the audit 
data generated by wrappers or as a pre-processor to the SNORT open source IDS. 
The constraints developed using the methodology are highly effective in detecting 
intrusions. In addition, the development process is not just based on existing 
attacks and vulnerability, but also knowledge on the system, its functionality, 
and historical behavior. We strongly believe that the best rules for distinguishing 
intrusions from legitimate activity have to take all these aspects into account. 

Future work on this project will include developing different types of con- 
straints for more components and evaluating their effectiveness. In addition, it 
is important to identify a way to measure or estimate the effectiveness of con- 
straints as well as the cost of monitoring the constraints to allow analysis. Also, a 
methodology for tailoring the constraints to a specific environment is required. It 
would also be helpful to have a unified language for specifying the constraints so 
that it can be automatically translated to an enforceable representation. Last, 
a formal methodology for reasoning about the constraints would be useful to 
understand the overall policy achieved by the constraints. 
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